Deprecate broccoli CSS pipeline for vite app css #1148
Conversation
|
|
||
| ## Detailed design | ||
|
|
||
| Replace the CSS import in our app blueprint to the file on disk. |
There was a problem hiding this comment.
This should be clear that we'd only deprecate it for vite-based projects. Classic build, while not default, is still supported.
There was a problem hiding this comment.
I've added wording that this only affects vite projects and not classic build projects.
|
|
||
| ## How we teach this | ||
|
|
||
| As part of a deprecation guide explain how to keep using the broccoli pipeline whilst they migrate (using `/@embroider/virtual/app.css`) |
There was a problem hiding this comment.
It looks like you started with the regular RFC template, rather than the Deprecation template. For a deprecation RFC we need to write the deprecation guide for 'How we teach this' as well as enumerate anywhere in the API docs or guides that needs updating in light of the deprecation.
There was a problem hiding this comment.
I've updated to use the deprecation template and added wording for a deprecation guide, also checked for anything we'd need to change in the guides or api docs (we don't need to).
|
|
||
| ## Drawbacks | ||
|
|
||
| None that I can think of. |
There was a problem hiding this comment.
I can think potential drawbacks:
- Addon CSS no longer ending up in your pipeline in the same manner
- Should we be deprecating compat feaures one-by-one?
There was a problem hiding this comment.
There are so few addon css things tho.
I haven't encountered any in years
Each compan feature may have a different migration guide... So... Maybe?
There was a problem hiding this comment.
Addon CSS no longer ending up in your pipeline in the same manner
/@embroider/virtual/vendor.css will still be used so V1 addons that provide CSS should still end up in vendor.css
Should we be deprecating compat feaures one-by-one?
At the very least I think this one should be done sooner rather than later, this topic keeps coming up in the discord, especially when people are trying to use tailwind. It's the one thing I'm helping people with repeatedly.
There was a problem hiding this comment.
I'm just pointing out things that should be discussed in the 'Drawbacks' section
evoactivity
changed the title
|
|
||
| We would encourage you to migrate to the vite pipeline by adopting the right tooling as covered by https://vite.dev/guide/features.html#css-pre-processors | ||
|
|
||
| You can see examples of different CSS tooling being used in this repository https://github.com/evoactivity/ember-vite-css-examples/ |
There was a problem hiding this comment.
this is a really nice list
if we can add links to docs for how to set up all of this (we are no longer the source of truth for these integrations, but we can link folks to how to migrate), that'd be super good 🎉
NullVoxPopuli
added
S-Exploring
3 participants
Propose deprecating broccoli CSS pipeline
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP