v2 Addon spec as default
See original GitHub issueDocumenting some of the things that need to be done before v2 spec is the default for new addons, from a discussion with @ef4:
- prepublish tool that converts from colocated templates to explicit
setComponentTemplate
- Recruit from the learning team to write guides on how to create a v2 addon, and when v2 addon should be used vs v1
- Update ember-cli-update to also update nested test-apps for v2 addons
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
embroider/SPEC.md at main - GitHub
Compiling Ember apps into spec-compliant, modern Javascript. ... The default export is a class that implements your addon hooks (no base class is...
Read more >Migrating an Ember addon to the next-gen v2 format - kaliber5
This blog post walks you through the migration of an existing addon to Embroider's new v2 format.
Read more >v2 Addon Format (Embroider Compatibility) - Ember RFCs
v2 Addon Format (Embroider Compatibility) Summary This RFC defines a new package format that is designed to make Ember packages (meaning ...
Read more >LootSpecManager - Addons - World of Warcraft - CurseForge
Additionally, the addon now makes use of configuration profiles. By default a per character profile will be generated on first launch but you...
Read more >Performance addons operator advanced configuration
Default tunings are applied with the openshift-performance base profile, it is the base for creating a Tuned CR that would be detected by ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes, and @rwjblue has convinced me that we should push for the monorepo version as the default.
The main benefit of not using a monorepo has historically been the ability for people to point their package.json dependencies directly at your repo, but since most v2 addons will have a build step anyway that already doesn’t work. So there’s not really a downside to using a monorepo.
I’m glad we are talking about this. I was planning on writing an RFC for monorepo addon + dummy app (as work time allows).