Skip to content

version 1.0 #742

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

Merged
merged 14 commits into from
Jul 6, 2018
Merged

version 1.0 #742

merged 14 commits into from
Jul 6, 2018

Conversation

alexander-akait
Copy link
Member

@alexander-akait alexander-akait commented Jul 4, 2018

What kind of change does this PR introduce?

refactor

Did you add tests for your changes?

already exists

If relevant, did you update the README?

yes

Summary

Roadmap:

  1. Merge this PR and release 1.0.0 version.
  2. Drop css modules in favor https://github.com/css-modules/postcss-modules
  3. Refactor code (get some usefull stuff from [WIP] refactor(loader): v2.0.0 #639) and webpack-default
  4. Release 2.0.0 version.

Does this PR introduce a breaking change?

yes

Other information

Let's do it

fixes #691 fixes #265 fixes #688 fixes #732

evilebottnawi and others added 13 commits May 2, 2018 16:05
# Conflicts:
#	test/simpleTest.js
BREAKING CHANGE: remove `minimize` option
BREAKING CHANGE: remove `module` option, use `modules` option instead
BREAKING CHANGE: remove `camelcase` option, use `camelCase` option instead
BREAKING CHANGE: remove `root` option, use `postcss-loader` with `postcss-url` plugin instead
BREAKING CHANGE: remove `alias` option, use `webpack` `resolve.alias` option
BREAKING CHANGE: minimum require `nodejs` version is `6.9`
@alexander-akait alexander-akait changed the title 1.0 version 1.0 Jul 4, 2018
@alexander-akait
Copy link
Member Author

alexander-akait commented Jul 4, 2018

/cc @ai

Can you help me with better integration postcss-loader with postcss-modules?

@ai
Copy link
Contributor

ai commented Jul 4, 2018

Sure. What I need to look?

@alexander-akait
Copy link
Member Author

@ai need find way how use postcss-loader with postcss-modules plugin (our pipeline https://github.com/webpack-contrib/css-loader/blob/master/lib/processCss.js#L189), maybe some values will be unavailable inside postcss-loader.

In short: need add example postcss-modules configuration with postcss-loader in README.

@ai
Copy link
Contributor

ai commented Jul 4, 2018

👍 will send you a PR in next few days

Copy link

@shellscape shellscape left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few notes. Should webpack-defaults be merged into this repo before or after this PR is merged?

@@ -7,20 +7,20 @@ matrix:
fast_finish: true
include:
- os: linux
node_js: "7"
env: WEBPACK_VERSION="2.2.0" JOB_PART=lint
node_js: "10"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we ditch travis and get on circle CI?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shellscape let's do this in other PR

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

var root = query.root;
var moduleMode = query.modules || query.module;
var camelCaseKeys = query.camelCase || query.camelcase;
var moduleMode = query.modules;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because this is a refactor, shouldn't we use const and let instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shellscape also let's do it other PR, when we ship webpack-default in this repo

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

package.json Outdated
@@ -36,6 +34,9 @@
"should": "^11.1.2",
"standard-version": "^4.0.0"
},
"peerDependencies": {
"webpack": "^3.0.0 || ^4.0.0"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new major versions of webpack-contrib and webpack org modules are only supporting webpack@4 moving forward. since this is a new major version, we should drop webpack@3 support.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Andrew, it's harder to keep compat when things move forward too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexander-akait
Copy link
Member Author

@shellscape i think we can update webpack-default after merge this PR, because problem with browserslist are ASAP

BREAKING CHANGE: minimum require `webpack` version is `4`
@codecov
Copy link

codecov bot commented Jul 5, 2018

Codecov Report

Merging #742 into master will decrease coverage by 0.18%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #742      +/-   ##
==========================================
- Coverage   98.43%   98.25%   -0.19%     
==========================================
  Files          11       10       -1     
  Lines         384      344      -40     
  Branches       90       76      -14     
==========================================
- Hits          378      338      -40     
  Misses          6        6
Impacted Files Coverage Δ
lib/loader.js 100% <100%> (ø) ⬆️
lib/localsLoader.js 100% <100%> (ø) ⬆️
lib/processCss.js 98.54% <100%> (-0.13%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1703721...8db3fb0. Read the comment docs.

@sokra
Copy link
Member

sokra commented Jul 5, 2018

There are few more breaking changes possible, but that should be considered carefully:

Dropping ~ requests, urls -> requests

Currently it behaves like this:

url("./something") -> require("./something")
url("something") -> require("./something")
url("~something") -> require("something")

We can consider dropping this logic:

url("./something") -> require("./something")
url("something") -> require("something")

The logic was there for best compatiblity with existing stylesheets, but this may not be thing for everybody.

As workaround one can do this:

module.rules: [
  { test: /\.css$/,
    use: [MCEP.loader, "css-loader"],
    resolve: { modules: [".", "node_modules"] }
  }
]

which will change the logic to this:

url("./something") -> require("./something")
url("something") -> require("something") but looks in the current directory too.

For backward-compat ~ could be supported but deprecated. Or a separate loader can do the transform for backward-compat.

Dropping importLoaders

Currently when using @import (and it's done by the css-loader, which is not the case when using sass or postcss-import) X loaders are copied to the inner require. X = importLoaders.

This is important to not apply the style-loader to inner requests, because that doesn't work.

When dropping importLoaders you have to manually make sure that style-loader is not appied to inner requests, i. e. with these rules:

module.rules: [
 { test: /\.css$, rules: [
    { issuer: { not: /\.css$/ }, use: "style-loader" },
    { use: "css-loader" }
 ]}
]

Similar rule for MCEP.

ESM exports

When using "locals" (modules) the locals could be exported as ESM exports. This would make the result a ESM. For backward-compat expose it as named exports and all exports as object via default export.

@@ -36,6 +34,9 @@
"should": "^11.1.2",
"standard-version": "^4.0.0"
},
"peerDependencies": {
"webpack": "^4.0.0"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this. The codebase does not require('webpack'). I understand that you added this to avoid runtime errors when webpack's version is not the expected one but I don't think this is the correct solution.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ooflorent we use this for all webpack-contrib repos, better create issue in webpack-default about this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ooflorent Also it is prevent problem with using webpack api between version, if somebody want use css-loader on webpack@3, they can use old version

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it's a standard for webpack-defaults. that peerDep on webpack has been in defaults for a very long time. along with the Requirements section in the defaults README, this serves as a warning to keep people on supported versions of webpack. new major versions of loaders/plugins/utils are webpack@4+ and Node 6+ only.

@alexander-akait
Copy link
Member Author

Let's do it and do css-loader better in future

@alexander-akait alexander-akait merged commit 240db53 into master Jul 6, 2018
@alexander-akait alexander-akait deleted the 1.0 branch July 6, 2018 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants