Remove parcel

[wirednkod]

Parcel should be removed from repo as it is blocking node v18 to be added in the CI ( #990 ) with error:

@parcel/optimizer-terser: You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ...
}) before using SourceMapConsumer

This is a [known issue[(https://github.com/mozilla/source-map/issues/432) and can probably be solved with adding the proposed "source-map": "^0.8.0-beta.0", (have not tried). Since we are using parcel just for the landing page and was very easily replaced with webpack, I preferred to spare us with the extra dependency (plus remove the parcel dependencies).

[raoulmillais]

Missed a reference to parcel in the connect tsconfig.json

[raoulmillais]

I think it would be preferable to move common webpack configuration into a file in the root and then merge it with the specifics for each project instead of copy/pasting it around.

[wirednkod]

Sure. This can be done in different PR though. The purpose of this pr is to remove parrcel, and not create common configs

[raoulmillais]

ok 👍 but let's do this quickly after this merges

[tomaka]

to move common webpack configuration into a file in the root

But why?
There's nothing wrong with configuring multiple projects differently, and if projects can in theory have different configurations, then their configuration files should be separate.
It's not because files are similar that you should de-duplicate them. You should only de-duplicate them if it makes sense for the multiple different projects to always conform to the same configuration, which isn't the case.

[raoulmillais]

It is the case. The vast majority of the webpack configuration is identical across landing page, burnr and the demo. It's true that they can in theory be different but in practice they're not. It's not easy at the moment to see what's specific about the configuration for each project and if you make changes to the webpack configuration you have to remember to do it in all the places for them to stay consistent. The configuration for:

• babel
• css loading
• HTML plugin
• typsecript loading

is always going to be the same across these projects. If we change them we're going to want to change it everywhere. Having it one place makes that less laborious

[wirednkod]

IMO webpack configurations should be dedicated per projects. Finding common parts of the existing configurations and making a common one, which then will be inherited to the rest ones, and then will add the extra configs - makes it more spaghetti than simple.

Common parts of webpack configs are very little and in some cases even these are different. A good example is the ts-loader where in demo we use it without extra options while in burnr we add options like transpileOnly and projectReferences. I would say that its better to narrow down the webpack confg per project and remove unnecessary parameters that probably exists due to copy/pasting and if there is some obvious added value then to create a common webpack file.

[tomaka]

if you make changes to the webpack configuration you have to remember to do it in all the places for them to stay consistent.

If you merge all webpack configurations into one, then if you make changes to the webpack configuration you have to make sure that all projects still work.

[raoulmillais]

I'm not advocating merging it all into one .. just pulling the common boilerplate out

[wirednkod]

Added an issue