Import Plugin #906

Open
ai opened this Issue Oct 26, 2016 · 42 comments

Projects

None yet

9 participants

@ai
Member
ai commented Oct 26, 2016

Right now we have a some mess in @import plugins:

  • postcss-import doesn’t provide out-of-box solution for most of developers and still looking a maintaier.
  • postcss-easy-import has more features, but base on top of frozen postcss-import
  • postcss-partial-import is good, but has not all of user request’s features.

Right now I am a fan of postcss-smart-import, because it has active development and has a lot of features.

Anyway, right now we have a UX problem, because new PostCSS users doesn’t know what to add and have many problems with @import. As result they become disappointment of entire PostCSS ecosystem (“plugins hell”, “bad support”) and leave it.

I think that we should choice one plugin and deprecate others one. We could move some missed features to winner plugin. Maybe we should also rename winner plugin to postcss-import.

@MoOx @TrySound @jonathantneal @swernerx what do you think?

@jonathantneal
Contributor

Active development comes in waves for all projects, as each one gains new maintainers or adds new features.

  1. I’m fine to map and merge features into a new postcss-import update, credit all authors, and work together moving forward.
  2. With the breadth of plugins now available, it’s worth discussing the formation of a committee that white-lists plugins (perhaps we could even get a shield).
@dan-gamble
Contributor

I remember when i came in a while ago when there was only 2 and that still threw me a bit. I agree with @jonathantneal 1st point

@simonsmith
Contributor

because it has active development and has a lot of features.

Is it identical to postcss-import? The README is almost the same

I opened this issue on smart-import as I'm unsure of its purpose. It's great that's actively maintained but if it inherits all the bugs in postcss-import then we've doubled the problem. Hopefully it can be clarified.

The most direct route is to try and attack some of the postcss-import bugs. Whilst we could revert it to 7.x it would lose some of the features that were added. It perhaps just needs refactoring, although it's not a simple task.

Might just need someone to start understanding the codebase. I might clone it later and start looking.

@ai
Member
ai commented Oct 26, 2016 edited

@simonsmith unfortunately right now we have a few big problems in postcss-import:

  1. It doesn’t support .sss or .scss imports out-of-box by design.
  2. It doesn’t support globbing out-of-box by design.
  3. Current postcss-import v8 branch has too many issues and @MoOx just want to return to v7 and start again.
  4. postcss-import has no development. This issue is critical for postcss-loader 1.0: postcss/postcss-import#233

But agree, we should fix a postcss-smart-import docs.

@simonsmith
Contributor

@ai Does smart-import address any of those issues?

@ai
Member
ai commented Oct 26, 2016

@simonsmith let’s ask @swernerx

@MoOx
Member
MoOx commented Oct 26, 2016

smart-import is a fork (unforked). This person should have asked or make PR to postcss-import imo.

Again, you talk like if there is a community, but there is mostly "just users" as this issue prove it postcss/postcss-import#210 (still no response, or maybe more "no actions"...)

@simonsmith
Contributor

There is a PostCSS community and we're here to try and sort out a plan for postcss-import. This thread right now is an action.

@ai
Member
ai commented Oct 26, 2016

Yeap postcss-smart-import looks like “just postcss-import in development. So maybe we should just rename it to postcss-import?

@MoOx
Member
MoOx commented Oct 26, 2016

or just make a PR to postcss-import. Looks more legit.

@ai
Member
ai commented Oct 26, 2016 edited

@MoOx you are looking for new maintainer, isn't you? In this case you should increase developer enthusiasm by giving more responsibilities. Unfortunately, non-strict instructions (what PR, for example) kills enthusiasm. For my experience, this it could be a main reason why you still didn't find a new maintainer.

In my experience there is two steps to transform a regular user into a open source maintainer:

  1. Strict steps instructions (for instance, add this feature to this function in this file, add test, and a PR).
  2. Responsibilities.

So my current plan is:

  1. Pick a smart-import features that should be backported to postcss-import.
  2. Pick a partial-import features
  3. Add @swernerx (and @jonathantneal) as maintainers.
  4. Finish import crisis.

Guys, what do you think?

@MoOx
Member
MoOx commented Oct 26, 2016

you are looking for new maintainer, isn't you? In this case you should increase developer enthusiasm by giving more responsibilities. Unfortunately, non-strict instructions (what PR, for example) kills enthusiasm. For my experience, this it could be a main reason why you still didn't find a new maintainer.

I am not looking for anything, the community does. I stopped actively maintaining it because I don't actively use it. For the same reason I am not spending time on "looking for" people to take the lead.
FYI, as a "user", when I see a project is not actively developed, I start to answer to issues, make some PRs to get trust of owner/maintainers (even if not active), then I ask for right to collab/publish. That's own open source work right? I should not have to cry for help or tell people what to do.

I am more a "if you want to help, all contributions are welcome". Then people start to help by themselves and ask for instructions. This scenario is currently happening with the project I am actively developing (Phenomic) and we are now 6 maintainers (and I never asked some help me, people wanted to, asked how to help on specific issues directly...)

So you current plan is nice, you can add however you want to postcss-import since you have the correct right for it. If someone need some npm rights, just poke me with your npm username.

Here are some instructions tho postcss/postcss-import#210 (comment)

@swernerx
swernerx commented Oct 26, 2016 edited

It's interesting.

I am just starting to follow this thread.

PostCSS Smart Import was a fork of PostCSS Import, right.

It has different goals though. It has larger goals.

The first thing is that I updated all the deps.

Then I removed all the media query handling for imports. PostCSS Import claims it follows the CSS spec here. I don't care about that. In my opinion the CSS spec of imports is not that interesting for doing a PostCSS plugin for the typical "Webpack world". For me the main reasons for the removal was simplification. A cleanup step for bringing new features in for a next step.

I think that the whole URL handling + import area is pretty unstable right now. Especially as there are a lot of tools building up on PostCSS using other functions e.g. asset-width but with the same plain CSS-relative URLs. A PostCSS import plugin should IMHO handle all these steps correctly without delegating this to the user adding another plugin.

As mentioned in the readme of postcss-smart-import: I like to have a feature combination of postcss-import + postcss-url + postcss-assets + ... inlining / svg spriting / etc. inside one plugin.

IMHO keeping postcss-import with the original feature scope alive is not that intesting for me. IMHO these plugin should implement whole scopes instead of just one area. At least from my point of view where the huge plugin environment with tons of separate plugins (all have to be executed in the right order) is quite cumbersome.

PostCSS Smart Import is implemented in a side project for my day-to-day job. It's not anything I get actively paid or supported for. As most open source it's just that I required something for myself and there was no value in keeping it closed.

@michael-ciniawsky
michael-ciniawsky commented Oct 26, 2016 edited

@swernerx what is your opinion on making it a preset instead of a plugin e.g

postcss.config.js

module.exports = (ctx) => {
  return {
   parser: ctx.ext === '.sss' ? 'sugarss' : false,
   plugins: {
     'postcss-preset-imports': {...options} // e.g postcss-import, -url, -assets => {Array}
     'postcss-plugin': {}  // => {Function}
     'postcss-preset-cssmodules': {},
     'postcss-preset-cssnext': {}
  }
}

common config will support it with next release. Other ideas/feedback welcome :)

Besides that, atm it looks like postcss-smart-import , as you mentioned, is a clean and updated version of postcss-import. For the matter of fact and as a starting point here at postcss-import would it be possible to send your efforts as PR before you continue envolving postcss-smart-import?

@swernerx
swernerx commented Oct 27, 2016 edited
  • As I said it has a different scope. So I do not think a PR makes sense. It reduces features e.g. the media query based imports.
  • I do not like to put sensible default behavior into a config/preset file so that every user has to care. We now what extensions e.g. are used for sugarss, etc. We just have to handle them right. Same with asset paths.
@michael-ciniawsky
michael-ciniawsky commented Oct 27, 2016 edited

The revert from v8.x to 7.x currenty discussed would remove media query based imports aswell if I got that right and since the necessary cleanups (which you already did), is on the list of whomever will be the maintainer of postcss-import anyways, it as more in the direction, if you would be so polite to make your efforts available here.

The preset example above may be misleading, it's not necessary to config anything, although possible, it ships with defaults e.g like PreCSS / CSSNext. The distinction in terms of scope, between what 'is' a plugin (e.g do one thing and do it tell bla bla 😛 ) and when to better use a package/preset is important imo. Currently there is no boilerplate/standard how to make a preset but this could/should be changed. Your idea is good and understandable in terms of daily reliable usage, but can we do better by finding a common way to compose plugins, so config/setup gets less painful for most of the devs using postcss? It's not arguing against your idea with postcss-smart-import if you prefer it that way go on with it, but maybe there is room for discussion.

@kevinSuttle

Poor attitudes in responses could be another reason why there is "no community" or no one willing to contribute...

@ai
Member
ai commented Oct 28, 2016

@swernerx I like waht you did in postcss-smart-import, but I am not big fan of integrating plugins into each other ;).

I see this problems:

  1. Users want the different syntax for different cases (like inline() from postcss-assest and url() from postcss-url).
  2. postcss-url is used in many hacks, where you didn’t want to have @import support. For instance, if user just want to set cache-buster to links.
  3. There is also SVG, where you need more smart solution like postcss-inline-svg.
  4. Users like the modularity idea.

But I agree that many users need all this plugins, and they want a zero-config, out-of-box solution.

What do you think about this steps:

  1. Unify assets plugins config. We already have a issue about it: #895
  2. Create a very small preset (because all assets plugins will use one parameters).
@michael-ciniawsky michael-ciniawsky referenced this issue in postcss/postcss-import Oct 28, 2016
Closed

Add dependency message #233

@RyanZim
Contributor
RyanZim commented Oct 28, 2016

But I agree that many users need all this plugins, and they want a zero-config, out-of-box solution.

Well said! A few thoughts on how to do that:

  1. Use sensible defaults (pretty good in the postcss ecosystem, would prefer a few changes to postcss-url's defaults; bikeshed that somewhere else 😉 ).
  2. Plugin packs/presets (like Babel) are a good idea; postcss should have more, and someone should write a boilerplate or lib to streamline making plugin packs.
  3. Users that want a streamlined, complete no-configuration tool can build things like standard (a wrapper around eslint).

I am not big fan of integrating plugins into each other

👍 I think we need a good @import plugin and a plugin pack that includes postcss-url, etc.


I am pretty strapped for time ATM, but I would be willing to help/maintain an import plugin.

@ai I like your plan in #906 (comment). What repo should this be done in; and which plugin@version should we use as the code to work off of?

@RyanZim RyanZim referenced this issue in postcss/postcss-cli Oct 28, 2016
Closed

--watch mode doesn't always work correctly #44

@michael-ciniawsky

Plugin packs/presets (like Babel) are a good idea; postcss should have more, and someone should write a boilerplate or lib to streamline making plugin packs.

|-index.css
|-postcss.config.js
|-node_modules
|  |-postcss-preset/[config]-awesome
|     |-package.json
|     |-index.js
|     |-[postcss.config.js]

postcss-preset-awesome

package.json

{
  "name": "postcss-preset-awesome",
  "version": "1.0.0",
  "description": "Awesome Preset for PostCSS",
  "engines": { "node": ">=4", "npm": ">=3" },
  "main": "index.js",
  "dependencies": {
     "postcss-load-plugins": "^2.0.0",
     "postcss-plugin": "^1.0.0",
     "postcss-plugin": "^1.0.0",
     "postcss-plugin": "^1.0.0",
  },
  "postcss": { 
     "plugins": {
        "postcss-plugin": {...defaults},
        "postcss-plugin": {...defaults},
        "postcss-plugin": {...defaults},
      }
   }
}

index.js

import pluginsrc from 'postcss-load-plugins'

const ctx  = {...defaults} || {}
// Could also be used to set plugins/preset defaults, instead of, like above, done in package.json 

pluginsrc(ctx, __dirname).then((plugins) => module.exports = plugins) // {Array}

Usage

postcss.config.js

module.exports = (ctx) => {
  return {
    parser: 'sugarss'
    plugins: {
     'postcss-preset-awesome': {},
    }
  }
}

Users that want a streamlined, complete no-configuration tool can build things like standard (a wrapper around eslint).

👍 Same as above but with postcss-load-config instead of postcss-load-plugins

Another way would be like PreCSS does it.

@ai
Member
ai commented Oct 31, 2016

@MoOx we found a good maintainer for postcss-import are you ready to take this heavy work from you?

because I think we should work at postcss-import next major.

@MoOx
Member
MoOx commented Nov 1, 2016

PR are always welcome. A good PR will be enough so I can give all required rights to the right people :)

@RyanZim
Contributor
RyanZim commented Nov 2, 2016

I did some digging in the source code, and I just can't get to the bottom of postcss/postcss-import#168. @ai I hate to do it, but perhaps we should revert to v7? Of course, if someone can point me in the right direction, perhaps I can fix v8. @TrySound ?

@jonathantneal
Contributor

It looks like the existing postcss-import has a very strong, lite core. My recommendation would be to turn every feature (even some currently in the core) into an external feature that can hook itself into that core. Sorry if I’m getting off topic.

@ai
Member
ai commented Nov 2, 2016

@jonathantneal I totally agree, that modularity is awesome for internal architecture.

But my experience in PostCSS maintaining showed to me, that modularity is not so good in end-user UX.

Right now main complain about PostCSS is that users ned a hours to configure a simple build process. Imagine how that are disappointed, when they need to search, select and fix compatibility problems between plugins of PostCSS plugins 😉.

This is why in my opinion, we should focused to give solutions, not features and plugins. Most popular features should be work out of box, without configuration.

This is the reason, why I so disappointed about current postcss-import state.

You need to 5 lines config for simple features like importing SugarSS files and add dependency to webpack.

@ai
Member
ai commented Nov 2, 2016

@RyanZim do postcss-smart-import has this "v8" issues?

@ai
Member
ai commented Nov 2, 2016

@MoOx let's just change a postcss-import maintainer without PRs. I think postcss-smart-import author showed, that he is aa good maintainer.

@RyanZim
Contributor
RyanZim commented Nov 2, 2016

@ai If I tested correctly, yes; postcss-smart-import has that issue. postcss/postcss-import#168

@ai
Member
ai commented Nov 2, 2016

@swernerx what ssh you think about that issue? Should we downgrade plugin or it could be fixed in current architecture?

@RyanZim
Contributor
RyanZim commented Nov 2, 2016

FWIW, it appears to be a race condition in nested import loading. Make sure to use the test at postcss/postcss-import#169; otherwise the issue is intermittent.

@MoOx
Member
MoOx commented Nov 2, 2016

@ai the idea is not be be a good maintainer or not. The idea is to care about the module and the goal of the module. postcss-"smart"-import is just postcss-import with less and others features that should definitely not be in a module that inline @import. So you should better fix postcss-import issues first, then provide (like you said) a good UX with high level package that rely on postcss-import, like @TrySound tried to do with postcss-easy-import.

@swernerx said itself:

Then I removed all the media query handling for imports. PostCSS Import claims it follows the CSS spec here. I don't care about that.

@RyanZim
Contributor
RyanZim commented Nov 2, 2016

IMO, if someone can fix postcss/postcss-import#168 or point me in the right direction to fix it, we can work with the current architecture. If not, we'll be forced to revert.

@ai
Member
ai commented Nov 2, 2016

@MoOx if you really want core module idea we could rename postcss-import to postcss-import-core and use postcss-import for full-features version.

Current problems with postcss-import + postcss-easy-import:

  1. Users see postcss-import plugin, take it and didn’t find a features. You must to be deeply into PostCSS community to find postcss-easy-import. See downloads stats. So, shorter and clear name is really important.
  2. You still need to configure postcss-easy-import. It couldn’t just load SugarSS out of box. Even for globbing you need to read docs and find right option.
@ai
Member
ai commented Nov 2, 2016

@MoOx I understand that you like W3C compatibility idea.

But right now postcss-import doesn’t have a maintainer. There is very important dependency message issue and you didn’t even ask for PR.

So, from my point of view, any maintainer (but I think @swernerx is good) is better, that no maintainer at all. Especially for so critical plugin like postcss-import.

Could you collect what philosophy is important in postcss-import. We could discuss it together and you could free this plugin for promise not to break this philosophy.

@MoOx
Member
MoOx commented Nov 2, 2016 edited

Maybe you should just wait for a response from @swernerx before assigning him... He said he is not interested in the core idea of postcss-import (which mostly stick to following the css specs) and he has larger goals (but without following the entire specs, since he removed support for mq...). @swernerx correct me if I am wrong :)

But right now postcss-import doesn’t have a maintainer. There is very important dependency message issue and you didn’t even ask for PR.

If this was really important, everybody were adding stupid "+1" in the issue, so it's probably not that important haha (just kidding).

I am still taking time to handle the mess of the repo, trying to help you, right here, right now. Because I am concerned about users even if I don't push any update to the actual package.

I totally understand your concern about simplicity etc. I just don't want people to write code that won't work in browser natively, but maybe I should stop bothering you with this.

@RyanZim seems to be the correct person to give full power because it's the only person that tried to investigate on the past few months.

If you really want the npm name, just ask for this explicitly, but I would prefer to give rights to a person actually working to make things better, even if he is adding non standard things, instead of not asking for help or not opening discussions, because that's how open source works (right?)

@ai
Member
ai commented Nov 2, 2016

I am OK with @RyanZim too :). @RyanZim do you want to be a postcss-import maintainer?

@RyanZim
Contributor
RyanZim commented Nov 2, 2016

@ai I would be willing.


Disclamer:

To be honest, postcss/postcss-import#168 has me stumped harder than any other bug I've ever encountered. That bug is the only reason I haven't fixed postcss/postcss-import#233 yet. I don't want to fix it only to revert to v7 & do it all over again in a few weeks!

I'm going to discuss postcss/postcss-import#168 a little with @MoOx, see if we can figure it out.

@RyanZim
Contributor
RyanZim commented Nov 3, 2016
@simonsmith
Contributor

Great work @RyanZim

@ai
Member
ai commented Nov 4, 2016

@RyanZim could you send PR with dependency message too? postcss/postcss-import#233

@MoOx so, let’s change a maintainer and start picking a features?

@MoOx
Member
MoOx commented Nov 4, 2016

He already have all the rights and started to check and respond to issues.

@RyanZim
Contributor
RyanZim commented Nov 10, 2016

dependency message added: postcss/postcss-import#241

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment