Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webpack 5 Support & 1.0 meta issue #880

Closed
10 tasks done
weaverryan opened this issue Dec 31, 2020 · 2 comments
Closed
10 tasks done

Webpack 5 Support & 1.0 meta issue #880

weaverryan opened this issue Dec 31, 2020 · 2 comments

Comments

@weaverryan
Copy link
Member

weaverryan commented Dec 31, 2020

Hi!

This issue tracks things that we want to get done before releasing a 1.0 of Encore with Webpack 5 support:

@versedi
Copy link

versedi commented Dec 31, 2020

H) Decide on a backwards-compatibility (BC) promise related to Webpack dependencies (e.g. if we bump @babel/core from v7 to v8, does that require a new major version of Encore? OR what if we drop support for sass-loader v9 (which is a library version that the user controls) - does that require a new major version of Encore?

IMHO it shouldn't rely on the major/minor update of the dependency's version, but instead on the fact if the dependency update breaks anything inside encore - eg. configuration syntax changes or behaviour of something changes.

if we bump @babel/core from v7 to v8, does that require a new major version of Encore?

Upgrade from v6 to v7 had some breaking changes IIRC in default set of plugins. I'd say it depends...

what if we drop support for sass-loader v9 (which is a library version that the user controls)

Yes. New major.

Now that I think about it, maybe the question should be - should encore try to force anything at all via versions.

From one side of the coin if it's the user's dependency he should be aware of what he's doing. From other this would require pages of changelog where anything people use is no longer supported and if not would probably cause an influx of issues.

weaverryan added a commit that referenced this issue Jan 22, 2021
… (weaverryan)

This PR was squashed before being merged into the main branch.

Discussion
----------

Updating images and fonts to use Webpack 5 Asset modules

This is one more big piece for proper Webpack 5 support - see #880

This also updates the CHANGELOG both for this PR and for the original in #645

And, this adds a new assertion method that helps check directory contents in functional.js in a way that is more resilient to hash changes.

For the most part... this just worked! See the CHANGELOG. Because this will release on 1.0, I have decided to remove a few methods instead of deprecating them ).

Cheers!

Commits
-------

55495cf changing the default to asset/resource
a663fbc moving require into loader function
8d3b401 fixing tests on the lowest deps due to version upgrades
3e9c787 Making tests more resilient to failure by fuzzy checking some hash filenames
d86e115 upgrading Webpack min
64c6c2f updating CHANGELOG for original Webpack 5 changes in #645
16c0f12 Updating images and fonts to use Webpack 5 Asset modules
weaverryan added a commit that referenced this issue Jan 23, 2021
…pack 5 persistent caching (weaverryan)

This PR was squashed before being merged into the main branch.

Discussion
----------

[Webpack 5] Adding new enableBuildCache() method for Webpack 5 persistent caching

Hi!

This is a very simple feature, but it can also easily be improperly used. It is part of #880. See some comments about it from @Lyrkan from #645:

> Things can easily go wrong with persistent caching... even only enabling it for the config file could lead to some issues if not done properly (for instance if the config use values coming from environment variables, which is far from an edge case imo: https://github.com/webpack/changelog-v5/blob/master/guides/persistent-caching.md#version).

The trick, for us, is to:

A) Make sure we are doing everything as correctly as we can. For example, I assume that WE don't need to include `.babelrc` or `postcss.config.js`, but I actually don't know that for sure. Should we also potentially be adding Encore itself to the build dependencies?

B) Good communication in the documentation above the method and in the (eventual) recipe where we include this in the user's webpack.config.js file

## TODO

* [ ] 1) Test in a real project to see if we're missing anything (also play with what the valid keys are under `buildDependencies` - other than `config`, this is not documented anywhere).
* [x] ~~2) Check into Stimulus: I'm curious if `controllers.json` will need to be added to the build dependencies. I'm also curious if the UX vendor libraries will need to be in the build dependencies, as these do not follow the normal versioning (i.e. their directories in `node_modules/` can change without a change to `yarn.lock` or `package.json`)~~ should be solved by linked changes in #888

Cheers!

Commits
-------

a592c82 lint
9f117a4 fixing test
7a39654 Adding new enableBuildCache() method for Webpack 5 persistent caching
@weaverryan
Copy link
Member Author

About dependencies:

A) If we bump a major version of our direct dependencies, then would require a new major version of Encore if it can (in any reasonable way) affect our users. For example, a new version of semver would not affect our users (this is used internally for our own purposes) but a new version of babel could reasonably affect users.

B) If we bump a major version of a devDependency like sass-loader, then this is actually just a recommendation on what the user needs to have installed. Upgrading Encore does not actually upgrade their dependency. So, no new major version of Encore is needed. Of course, if we needed to change our integration with sass-loader (so that the old sass-loader will suddenly not work with the new version of Encore), then that would require a major break. In general, we would try to not "remove" support for old devDependency versions during minor Encore versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants