Webpack Entry Points - Proposal

[janrembold]

Currently all *.ts files are used as webpack entry points. Especially in components these are way too much. This also affects performance of the (already unstable) webpack-stream task.

We have two places were TypeScripts can be found:

1. Resources (globally available)
2. Components (modular and component specific)

My proposal would be to limit entry points in component scripts from:

const webpackSourcePatterns = [
    path.join(config.global.cwd, config.global.src, config.global.resources, '**', '*.ts'),
    path.join(config.global.cwd, config.global.src, config.global.components, '**', '*.ts')
];

to

const webpackSourcePatterns = [
    path.join(config.global.cwd, config.global.src, config.global.resources, '**', '*.ts'),
    path.join(config.global.cwd, config.global.src, config.global.components, '**', 'index.ts')
];

[janrembold]

Does anyone see any drawbacks I don't see on this approach?

[alxbenz]

Wouldn't this force a naming convention for our ts files? Currently we are naming the files like the corresponding component, i.e. jquery.accordion.ts.

[janrembold]

@alxbenz This would force a convention for TS file names inside components only. With this convention there would be only a single entry point for a components' script. Our component scripts get more and more complex and with the upcoming web components, state, external business logic, adapters and so on we will have much more TS files in the future. But only a single entry point is needed for each component.

All global resource plugins would remain as is. In most cases those scripts do not rely on imported files. So mostly all of them are entry points. In my opinion those files will be the minority in the future. Only global stuff like main.js (main.ts) should stay in resources folder in the future.

[SheepFromHeaven]

I like this approach, as we are not creating 'artificial' new naming conventions. As we would like to see our components as single 'modules' which we could basically load from npm we are just using the standard from there. npm modules normally start with an index.js/ts

[janrembold]

https://github.com/biotope/biotope-build/pull/89

[janrembold]

The entry point proposal wasn't fixed with the PR I commented above. So this is still an open issue.

I would like to propose two more things.

1. The entry points should be configurable, so that each project might overwrite it if necessary
2. As default I would propose this:

   const webpackSourcePatterns = [
   path.join(config.global.cwd, config.global.src, config.global.resources, '**', '*.ts'),,
   path.join(config.global.cwd, config.global.src, config.global.components, '**', 'index.ts'),
   path.join(config.global.cwd, config.global.src, config.global.components, '**', 'index.*.ts')
   ];

This adds all files that start with index.*.ts inside components folder. This would be an easy extension of the single index.ts entry point. Reason is that I think we might need different entry points in the future for web component styled components that use different environments, for example an entry point for plain component, one for JSON-LD-based component, attribute-based component and so on....

[timomayer]

Suggest we are doing that in 5.4 but we have to make sure we provide detailed migration guide

[janrembold]

This is not only a Webpack issue. We need to consider this naming convention for all entry points: SCSS, HBS, TS/JS

[jurekbarth]

My approach would be: If we think component based, every asset that belongs to a component should live in one folder: images, styles, scripts and html. In that folder everything called index.* is an entrypoint. Whatever else you need you could import somehow. Global styles are an issue for sure, scripts could be managed via treeshaking. Also we aren't that far away from dynamic imports and all kind of cool stuff. If we would go that route, we could also increase performance while developing, because we only needed to recreate one folder. So no matter how big a project would be, it could scale.

[janrembold]

@jurekbarth I think you described the status quo of our current discussion. We thought about prefixing all entry points (SCSS,HBS and TS/JS) with index.(scss|hbs|ts|js) to mark it as entry point.

I would like to also add index.*.(scss|hbs|ts|js) as well because of two different reasons:

1. The possibility to have more than a single entry point per component
2. To realize better readable file names, e.g. index.accordion.ts, index.accordion.scss etc...

[jurekbarth]

@janrembold Oh i did not read everything. Anyway why would i need more than one entrypoint per component? That would be a super narrow usecase, at least for me. We coule handle that via a custom entrypoint in the project config.

[timomayer]

After thinking about it, I agree that we should not offer multiple entry point options by default. It increases complexity with a very limited benefit. I vote for index.*.(ts|hbs|scss|js) this ensures readability when you have opened multiple components in your ide

[jurekbarth]

@timomayer why not just stick to convention with index.(ts|hbs|scss|js)? Not sure how ide's handle it, but it should be fine.

[janrembold]

@jurekbarth @timomayer IMO the readability of file names is reason enough to allow index.*.(ts|hbs|scss|js). Instead we end up with hundreds of index.hbs files and if we need this in the future we have to rework the patterns in the build process.

But the reason I came up with this issue were multiple entry points during my web component experiments. I had different entry points for a web component that is based on its state that was prefilled with JSON-LD or Attributes data out of the markup. So I had a index.componentName.json.ts (for usage in a CMS with JSON-LD data) and index.componentName.ts (for plain usage of the web component) script file. The first example script imports the second one as base class. That is necessary to support different environment scripts without polluting a single file with all functionality that might not be needed everywhere.

I don't think this additional convention hurts in any way and every developer can use it the way she wants.

[timomayer]

totally agree @janrembold . as said, i prefer to only have index.*.(ts|hbs|scss|js) because of the reasons you explained @janrembold i dont see why we should allow index.(ts|hbs|scss|js) in addition.

[janrembold]

@timomayer I think index.(ts|hbs|scss|js) is the godfather of entry point file names and this is pretty much the default name everyone is aware of. So I would like to keep this one too.

I was thinking a lot about those conventions and the way biotope handles them and would like to make this more configurable.

In this case it would mean that this pattern is configurable in the local projectConfig.js and if someone is crazy and really likes to name everything like foo.*.(ts|hbs|scss|js) as entry point she could go for it. There are lot more paths and patterns in biotope that could be made configurable and so be less forcing...

[timomayer]

i see the point of more freedome for a single ecosystem by make it configurable, but it makes sharing components between ecosystems more complicated.

[janrembold]

@timomayer I agree, the exchangeability of components is a totally valid point. But we still don't have an agreement on the entry point pattern.

I'm still convinced that both patterns index.* and index.*.* are valid and easy to understand and would like to go with that. We'll start the development for 6.0 next week and we need a decision until then to get it startet right.

[jurekbarth]

@janrembold i would suggest that you can add patterns in your config. So index.* would be a default and index.*.* would a config file addition. So we keep it simple and you can do whatever you prefer based on your config.

[timomayer]

@janrembold as discussed today: I am open to have both patterns build in, but do not make it configurable because of the already discussed exchangeability!

[SheepFromHeaven]

@timomayer I added configurable entry points (non breaking!) in #156 and I would not want to make the entry points unconfigurable. Per default I would use the index.ts pattern in the components folder and NO ts files in the resources folder. For this we should add the files to the config for files like a main.ts or a server.ts.

[SheepFromHeaven]

Closed for now. Reopen if needed.