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

fix: allow values in selectors to work correctly #894

Closed

Conversation

jquense
Copy link
Contributor

@jquense jquense commented Feb 15, 2019

This PR contains a:

  • bugfix
  • new feature
  • code refactor
  • test update
  • typo fix
  • metadata update

Motivation / Use-Case

depends on:

This works to enable behavior that is specced by css-modules, but has been only partially implemented until now; TL; DR; selectors are a valid place for imported values to be interpolated.

Breaking Changes

Maybe! Still thinking through that

Additional Info

@jsf-clabot
Copy link

jsf-clabot commented Feb 15, 2019

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Looks good. But:

  1. Need tests.
  2. Some developers can have same selector and @value test, it is potential breaking change.

@alexander-akait
Copy link
Member

And it is not bugfix, it is feature, we never support @values in selectors

@jquense
Copy link
Contributor Author

jquense commented Feb 15, 2019

yup i'm thinking through the breaking change case, Might make this all opt-in initially...

Will definitely add tests

@jquense
Copy link
Contributor Author

jquense commented Feb 15, 2019

I would call it a bugfix since the behavior is not supposed to be new, it's specced out by css-modules. That said, it's never worked and it adds new behavior so if you want to call it a feature i understand

@alexander-akait
Copy link
Member


if (typeof importIndex === 'number') {
if (replacement != null) {
Copy link
Member

Choose a reason for hiding this comment

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

Why not if (replacement) {}?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it could be! The old want needed to check for 0 but that's not the case anymore so lets do that!

Copy link
Member

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

Need fix CI problem with naming commit, please read CONTRIBUTING.md

@alexander-akait
Copy link
Member

Also please accept CLA

@jquense
Copy link
Contributor Author

jquense commented Feb 15, 2019

right so there are a few blocks to supporting this:

PR: css-modules/postcss-modules-values#2

This updates the values plugin so that it also replaces values in selectors. That behavior was always intended but it was using an old version of the icss utils that didn't support it.

PR: css-modules/postcss-modules-scope#4

Now that selectors are being replaced we run into a problem further down the chain in the scope plugin.

With the values PR this:

@value btn-class from './button.module.css'

.toolbar > .btn-class {
  margin-left: 10px
}

gets turned into:

:import('./button.module.css') {
  1__const_btn-class-0: btn-class
}

.toolbar > .1__const_btn-class-0 {
  margin-left: 10px
}

So that's what we want, the value of btn-class to be used as the class name here. Unfortunately the scope plugin with the default locals plugin will turn that selector into:

:local(.toolbar) > :local(.1__const_btn-class-0) {
 ...
}

This leads to the value identifier (1__const_btn) being hashed turning it into something like foo_module_12353-1__const_btn, which we don't want, because it removes the usage of the import.

This PR

The reason we need the last step is b/c after that pipeline we need to replace instances of import identifiers with a webpack require() to the file and the identifier there. Previously webpack wasn't checking in selectors for instances of local alias's so we needed to fix that.

@jquense
Copy link
Contributor Author

jquense commented Feb 15, 2019

Now that i'm thinking about it, it may be better to change the local by default plugin instead of the scope one...will check that

@alexander-akait
Copy link
Member

Okey, we need major release for this feature, it is normal, but we need more tests here and in plugins

@jquense
Copy link
Contributor Author

jquense commented Feb 15, 2019

yes I will add the tests, I wanted to make sure this wasn't going to be rejected out of hand before doing all that :)

The lint issue doesn't seem to be because of this. I've got the commit named correctly already i believe

@alexander-akait
Copy link
Member

@jquense just update lock file in other PR: rm -r node_modules && npm -r package-lock.json && npm install and send a new PR with new lock file, when we rebase this PR (security problems in some deps)

@alexander-akait
Copy link
Member

alexander-akait commented Feb 18, 2019

/cc @jquense PR looks good, but we have some big problems in some plugins and i think we should solve this problems, need solve #578 as patch release and when merge other PRs as major release.

Problem:
css-selector-tokenizer break some selector (you can see this in first post in issue), we should migrate on postcss-selector-parser because he has better compatibility. Plugins which should be migrate on postcss-selector-parser:

Can you help with this?

@jquense
Copy link
Contributor Author

jquense commented Feb 18, 2019

sounds good i can work on that yeah 👍

@alexander-akait
Copy link
Member

@jquense feel free to ping me

@alexander-akait
Copy link
Member

/cc @jquense friendly ping, now we can merge and release new css modules plugins version and release major version

@jquense
Copy link
Contributor Author

jquense commented Mar 7, 2019

ok updated the other PR, need that merged and released before I can easily write tests here!

@alexander-akait
Copy link
Member

/cc @jquense need rebase and fix CI, also can you provide link what should be merged first/second/etc, thanks

@alexander-akait
Copy link
Member

/cc @jquense friendly ping

@jquense
Copy link
Contributor Author

jquense commented Mar 26, 2019

Sorry, didn't realize I was the bottleneck. Everything is up to date on my end. Waiting on css-modules/postcss-modules-local-by-default#13 to be merged, should have been more clear, realized I just linked the issue

@jquense
Copy link
Contributor Author

jquense commented Mar 26, 2019

only css-modules/postcss-modules-local-by-default#13
then this. I closed the other PR the local-by-default PR replaces it

@alexander-akait
Copy link
Member

/cc @jquense sorry for very big delay, there are a lot of jobs, can you rebase and we release new version

@alexander-akait
Copy link
Member

@jquense Just clarify, css-modules/postcss-modules-values#2 need merge too?

@jquense
Copy link
Contributor Author

jquense commented May 6, 2019

README.md Outdated Show resolved Hide resolved
@jquense jquense force-pushed the fix-selector-value-interpolation branch from 03807ba to e2ae777 Compare May 8, 2019 13:22
@jquense
Copy link
Contributor Author

jquense commented May 13, 2019

@evilebottnawi this should be ready now 👍

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Great job, thanks!

@alexander-akait
Copy link
Member

alexander-akait commented May 13, 2019

/cc @jquense i think we should rewrite https://github.com/css-modules/icss-utils/blob/master/src/replaceValueSymbols.js and use this in our code instead own replaceImportsInString, can you take care about rewriting this in icss-utils? And we refactor code in next PR

@jquense
Copy link
Contributor Author

jquense commented May 13, 2019

sure I can look into that

@alexander-akait
Copy link
Member

@jquense thanks!

@alexander-akait
Copy link
Member

Let's do release on this week

@alexander-akait
Copy link
Member

alexander-akait commented May 28, 2019

/cc @jquense
Find interesting problem:

@value v-primary: #BF4040;
@value s-black: 'black-selector'; /* Problem here */
@value m-large: (min-width: 960px);

.primary-selector {
  color: v-primary;
}

.s-black {
  color: black;
}

@media m-large {
  .header {
    padding: 0 20px;
  }
}

I think we should fix it (or maybe better error message)

@jquense
Copy link
Contributor Author

jquense commented May 28, 2019

what's happening that seems wrong with the example?

@alexander-akait
Copy link
Member

@jquense error when you compile due this line @value s-black: 'black-selector'; /* Problem here */ (quotes)

@jquense
Copy link
Contributor Author

jquense commented May 29, 2019

I don't think this is a new issue?

@value color: 'black';

.s-black {
  color: color;
}

is possible now and also won't work. Agree that a nicer error would be good but I don't think that's in scope for this PR?

@alexander-akait
Copy link
Member

alexander-akait commented May 30, 2019

@jquense I already implement supporting @value in selector (in master), thanks for PR (my PR was inspired this PR), just find this error. Can you send other PR?

@jquense
Copy link
Contributor Author

jquense commented May 30, 2019

Ya you bet 👍 should we close this one then if you've pulled it in otherwise 😁

@alexander-akait
Copy link
Member

@jquense i keep open issue due we should fix problem what i describe above

@alexander-akait
Copy link
Member

/cc @jquense i can't do release before we can't fix problem with:

@value v-string: 'my-content';

.v-string {}

@jquense
Copy link
Contributor Author

jquense commented Jun 4, 2019

I'm sorry, i haven't had any time but i still don't understand why this is a blocker. The behavior of it not working is expected and consistent with the current v2 behavior for value interpolation.

@jquense
Copy link
Contributor Author

jquense commented Jun 4, 2019

Better, question what do you want it to do? having a selector with quotes is invalid, i don't think we should support that.

@alexander-akait
Copy link
Member

alexander-akait commented Jun 4, 2019

Error like: Error: string (\"'my-content'\") is not allowed in a :local block\, not just throw error with stack

@jquense
Copy link
Contributor Author

jquense commented Jun 4, 2019

Unfortunately I don't think is no good place to check for and throw this error (unless you have an idea). It would likely involve a big refactor of the css-modules pipeline in order to even notice it since it's related to behavior across multiple postcss plugins.

I agree that the behavior isn't great, but it's not new behavior and it's LESS bad than other cases like this which fail silently. I don't think we should make it a release blocker.

Overall i'd be happy to work on these things generally but i don't have any access to the key repos or the authority to make larger structural changes necessary to fix these sort of systemic issues with css-modules. Besides yourself no one else is responsive on any repo either

@alexander-akait
Copy link
Member

So we can't fix it in postcss-modules-local-by-default?

@jquense
Copy link
Contributor Author

jquense commented Jun 4, 2019

I don't think so...you'd only catch the ones for imported values, so your example above would still fail. We could try and put it in the values plugin but i'm not sure we know when the replacement is for a selector, since they all use the utils. I'd say we should put it in the utils module but that might be a larger scope than we'd want?

@alexander-akait
Copy link
Member

Maybe we just throw error on String node in postcss-modules-local-by-default? I think it is not difficult

@alexander-akait
Copy link
Member

Solved in postcss-modules-local-by-default

@alexander-akait
Copy link
Member

I think tomorrow will be release new major version

@jquense jquense deleted the fix-selector-value-interpolation branch June 5, 2019 02:47
@jquense
Copy link
Contributor Author

jquense commented Jun 5, 2019

awesome! glad you found a solution, I was thinking too hard about it 👍

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

Successfully merging this pull request may close these issues.

3 participants