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(ember): Fix backwards compatibility with Embroider changes #3230

Merged
merged 3 commits into from Feb 4, 2021

Conversation

k-fish
Copy link
Member

@k-fish k-fish commented Feb 2, 2021

Summary

Switching from ember-get-config to macros introduced a regression (#3181) for the classic build system, since Embroider injects runtime config differently depending on whether the app is using embroider for it's build system or not. This will grab the config and make it available to embroider/macros if embroider/core is not detected.

Switching from ember-get-config to macros introduced a regression for the classic build system, since Embroider injects runtime config differently depending on whether the app is using embroider for it's build system or not. This will grab the config and add it in the included hook when building the addon and including it in an app if embroider is not detected.
@github-actions
Copy link
Contributor

github-actions bot commented Feb 2, 2021

size-limit report

Path Size
@sentry/browser - CDN Bundle (gzipped) 20.38 KB (+0.01% 🔺)
@sentry/browser - Webpack 21.27 KB (0%)
@sentry/react - Webpack 21.29 KB (0%)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped) 27.32 KB (+0.01% 🔺)

Copy link
Contributor

@kamilogorek kamilogorek left a comment

Choose a reason for hiding this comment

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

2 questions, if they are fine, then go ahead and merge.

@@ -16,6 +16,21 @@ module.exports = {
},
},

getAddonConfig(app) {
const config = require(app.options.configPath)(app.env);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it always given that configPath will be at least defined? If not, then we should either wrap it in try/catch or if (!app.options || app.options.configPath)

Copy link
Member Author

Choose a reason for hiding this comment

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

config path should be always defined, since it's pulling the conventional config/environment.js which should always exist, but I think we can wrap this in try/catch anyway in case someone has an edge case 👍

},

included() {
this._super.included.apply(this, arguments);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same question here.

Copy link
Member Author

Choose a reason for hiding this comment

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

This super call should be fine.

@k-fish k-fish merged commit bb83006 into master Feb 4, 2021
@k-fish k-fish deleted the fix/ember-embroider-backwards-compatibility branch February 4, 2021 00:00
@Turbo87
Copy link
Contributor

Turbo87 commented Feb 7, 2021

@k-fish I just tried this out and it does not appear to work for me. I'm using an environment variable to switch between embroider and non-embroider builds but the condition in this MR assumes that as soon as the dependency exists it will always use embroider.

I've tried to hardcode the condition temporarily, but even then it does not appear to work since @embroider/macros can't find the config at runtime, due to app.options.configPath being undefined

@mydea
Copy link
Member

mydea commented Feb 9, 2021

It also breaks for me - I do not use embroider to build the app but have embroider/macros installed and use it for some stuff, so it tries to use the new config but fails at build time with a non-helpful message (Missing configuration for Sentry.), which is still a breaking change. I am OK with updating the config in our app to use the embroider syntax but this change was introduced in a patch-level release, so not really semver compatible 😬

k-fish added a commit that referenced this pull request Feb 9, 2021
As mentioned in #3230, this is still causing problems for build systems. Pulled out the logic to put config into an embroider macro to the 'config' hook for the addon, which gets rid of the conditional logic as well as pulling configPath which could be undefined. Tested on both sides of using Embroider and the existing build system and the macros appear to be populated now, so this should work.
@k-fish
Copy link
Member Author

k-fish commented Feb 9, 2021

@Turbo87 right, I hadn't considered the use case of flipping between systems, thanks 👍.

@mydea definitely should not be breaking still, the semver incompatibility isn't intentional, was hoping to roll forward the fix instead.

Just put up another fix that should work on both sides more cleanly now (using the config hook to receive config earlier so the macro's ownconfig is set properly), the fact that requiring configPath was working must have been specific to the dummy app when I was checking.

See #3246

k-fish added a commit that referenced this pull request Feb 16, 2021
* fix(ember): Fixing fetching config during build step

As mentioned in #3230, this is still causing problems for build systems. Pulled out the logic to put config into an embroider macro to the 'config' hook for the addon, which gets rid of the conditional logic as well as pulling configPath which could be undefined. Tested on both sides of using Embroider and the existing build system and the macros appear to be populated now, so this should work.
ahmedetefy pushed a commit that referenced this pull request Mar 10, 2021
* fix(ember): Fixing fetching config during build step

As mentioned in #3230, this is still causing problems for build systems. Pulled out the logic to put config into an embroider macro to the 'config' hook for the addon, which gets rid of the conditional logic as well as pulling configPath which could be undefined. Tested on both sides of using Embroider and the existing build system and the macros appear to be populated now, so this should work.
This was referenced Mar 14, 2021
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.

None yet

4 participants