Modes and Entry Points for 1.0

👨‍💻 Framework Development » Framework Design
1

This is my suggestion to solve some problems we have right now with modes:

  • No mode is "default" instead of "html".
  • “No mode” entry points don’t live in any folder, they live in the root.
  • Modes live in the folder of the same name. They fallback to default. This fixes the problem of creating new modes using packages that don’t support them directly.
  • We get rid of the src folder.
  • We move type from index.ts to type.ts.
  • client and server entrypoints can be joined in an index if not present. The future entrypoints (koa, inline, build, sw…) will be independent of this.
  • We solve the problem of unnecessary chunks in service workers by creating service workers while running webpack only with one entry-point.

Some examples.

/index.js # Both client and server for any mode.
/package.json

/client.js # Client for any mode.
/server.js # Server for any mode.
/package.json

/amp/index.js # Client and server for amp mode.
/index.js # Client and server for any mode other than amp.
/package.json

/amp/server.js # Server for amp mode.
/index.js # Client and server for any mode and client for amp mode.
/package.json

/mymode/index.js # Client and server for mymode mode.
/index.js # Client and server for any mode other than mymode.
/package.json

/amp/sw.js # Service worker for amp mode.
/index.js # Client and server for any mode.
/sw.js # Service worker for any mode other than amp.
/package.json

/index.ts # Both client and server for any mode.
/type.ts # Type of the package, to be imported by other packages.
/package.json

@development-team opinions?

2

This gets ugly pretty fast :confused:

And if we keep src then we don’t need to do this:

And the only import users ever had to do it’s direct:

import ExtensionExample2 from "@frontity/extension-example-2";

const settings: Settings<ExtensionExample2> = [
...
];

So I think I will maintain src.

The rest of the stuff is working great.

1 Like