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

Changes in environment.js applied only on second save #8478

Open
nfc036 opened this issue Mar 5, 2019 · 6 comments · May be fixed by #9489
Open

Changes in environment.js applied only on second save #8478

nfc036 opened this issue Mar 5, 2019 · 6 comments · May be fixed by #9489
Labels

Comments

@nfc036
Copy link

nfc036 commented Mar 5, 2019

I have properties defined in config/environment.js, i.e. testProperty with value 1:

'use strict';
module.exports = function(environment) {
  let ENV = {
    testProperty: 1,  
    modulePrefix: 'testapp2',
    environment,
    rootURL: '/',
    locationType: 'auto',
...

To illustrate the problem I import ENV from config in application controller and show the current value of ENV.testProperty in the application template.
Changing the value of testProperty from 1=>2 triggers a live reload, but the value shown in the browser is still "1" instead of "2" as expected. When changing the value from 2=>3, live reload is triggered again but not "3" as expected but "2" is shown (the value from the update before the last change).
Additional information:

  • when I add a console.log(ENV.testProperty') at the end of config/environment.js the console shows the (correct) current number twice before "Build successful".
  • when I change any other file leading to a live reload, the current state of environment.js is still not reflected in the application. I have to trigger a second save on environment.js to get the correct content.
  • restarting ember s always shows the current value correctly.

I noticed this with ember-cli@3.8.1 but checking with ember-cli@3.7.1 shows the same behaviour. It might be relevant that I'm working on windows.


Output from ember version --verbose && npm --version && yarn --version:

ember-cli: 3.8.1
http_parser: 2.7.0
node: 8.9.3
v8: 6.1.534.48
uv: 1.15.0
zlib: 1.2.11
ares: 1.10.1-DEV
modules: 57
nghttp2: 1.25.0
openssl: 1.0.2n
icu: 59.1
unicode: 9.0
cldr: 31.0.1
tz: 2017b
os: win32 x64
6.8.0
1.3.2
@rwjblue
Copy link
Member

rwjblue commented Mar 6, 2019

Hmm, I haven't seen/heard of this issue before now. I'll try to test tomorrow on OSX to see if the same thing is going on there and I just didn't notice...

@nfc036
Copy link
Author

nfc036 commented Mar 6, 2019

Thanks for looking into this, Robert. I didn't notice it before either. I checked one of my projects. When going back in time to Juli 2018 with ember-cli@3.3.0 everything worked as expected. In September 2018 I ugraded my app from ember-cli@3.3.0 to 3.4.2. The issue described above seems to start with this update.

@nfc036
Copy link
Author

nfc036 commented Mar 6, 2019

I noticed (using ember-cli@3.4.2) that broccoli is temporary creating files development.json and test.json in a config_loader-output_path-*/environments subdirectory. When changing config/environment.js and let ember-cli rebuild the application, test.json is correctly updated whereas development.json keeps the old content.

@nfc036
Copy link
Author

nfc036 commented Mar 6, 2019

While investigating this issue I noticed that when removing the if condition (to bypass the cache) here

if (config === undefined) {
config = this.configWithoutCache(env);
this.configCache.set(key, config);
}

changes in config/environment.js are applied on the first rebuild.

@gilgen
Copy link

gilgen commented Mar 26, 2019

@nfc036 I confirm this behaviour.

@colenso
Copy link
Contributor

colenso commented Sep 3, 2019

I'm experiencing the same behaviour.

colenso added a commit to x-b-e/ember-cli that referenced this issue Sep 3, 2019
colenso added a commit to x-b-e/ember-cli that referenced this issue Sep 3, 2019
colenso added a commit to x-b-e/ember-cli that referenced this issue Sep 26, 2019
locks pushed a commit that referenced this issue May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants