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

feat: Add method to configure loaders rules #509

Open
wants to merge 10 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@Kocal
Copy link
Contributor

Kocal commented Feb 2, 2019

This PR is a proposal to resolve #473 and #504 in a clean way.

Encore.configureLoaderRule() is a low-level function, and has for goal to let the user having full access to Webpack loaders rules (what we push into module.rules) and configure them.

This is the implementation of the idea I had in #504 (comment).

For resolving Vue files linting issue, the next example would be the ideal solution I think:

Encore
  .configureLoaderRule('eslint', loader => {
    loader.test = /\.(jsx?|vue)$/
  });

// actually, the equivalent code is something like this:
const webpackConfig = Encore.getWebpackConfig();
const eslintLoader = webpackConfig.module.rules.find(rule => rule.loader === 'eslint-loader');

eslintLoader.test = /\.(jsx?|vue)$/;

return webpackConfig;

For now, only ESLint loader is supported, but we can easily add other loaders.

Let me know what you think of this solution, thanks!

@Kocal Kocal force-pushed the Kocal:feat/configure-loader-rule branch from b5eeac2 to 5921b15 Feb 2, 2019

@Lyrkan
Copy link
Collaborator

Lyrkan left a comment

Hi @Kocal,

I didn't review this sooner because I was a bit skeptical about that new method... but all things considered it may not be a bad idea.

My main concern was that it would be really tied to Encore's internals.
For instance we recently changed the css-loader rule in order to support css modules (and there is a pending PR to do the same for the sass-loader, the less-loader and the stylus-loader).
If your method were already available before that change and someone used it to do something like configureLoaderRule('css', (loader) => { /* manipulate loader.use */ }) it would end up not working anymore (use doesn't exist at the root level anymore).

But since I also think that most people will use it to change the test part of the rule (which shouldn't change much) and that there is a warning about it being a low-level function... I'm not against adding it for the following rules:

  • js (or javascript?)
  • css
  • images
  • fonts
  • sass (and maybe an alias to scss?)
  • less
  • stylus
  • vue
  • eslint
  • ts (or typescript?)
  • handlebars

@weaverryan: What's your opinion on this?

Show resolved Hide resolved lib/WebpackConfig.js Outdated
Show resolved Hide resolved lib/config-generator.js Outdated
Show resolved Hide resolved test/loaders/eslint.js Outdated
Show resolved Hide resolved test/loaders/eslint.js Outdated

@Kocal Kocal force-pushed the Kocal:feat/configure-loader-rule branch from 5921b15 to 67a2ea8 Feb 8, 2019

@Kocal Kocal force-pushed the Kocal:feat/configure-loader-rule branch from cf582b3 to c502e48 Feb 8, 2019

@Kocal

This comment has been minimized.

Copy link
Contributor Author

Kocal commented Feb 8, 2019

The implementation (with tests) is done for:

  • javascript and its alias js
  • css
  • images
  • fonts
  • sass and its alias scss
  • less
  • stylus
  • vue
  • eslint
  • typescript and its alias ts
  • handlebars
Show resolved Hide resolved lib/WebpackConfig.js Outdated
@@ -682,6 +698,20 @@ class WebpackConfig {
});
}

configureLoaderRule(name, callback) {
logger.warning('Be careful when using Encore.configureLoaderRule(), this is a low-level method that can potentially breaks Encore and Webpack when not used carefully.');

This comment has been minimized.

@Lyrkan

Lyrkan Feb 8, 2019

Collaborator

Not entirely disagreeing with that warning but it may end up being a bit annoying to see it everytime you build if you have a legitimate reason of using configureLoaderRule().

This comment has been minimized.

@Kocal

Kocal Feb 8, 2019

Author Contributor

Well, everytime I'm running the dev-server I'm having the warning about the absolute public path and that's fine 🤷‍♂️

Do you have a better idea? 😕

Show resolved Hide resolved lib/config-generator.js Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment