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

enviornment.js flashMessageDefaults.sticky being ignored for prod build #162

Open
pjdicke opened this issue May 3, 2016 · 10 comments
Open

Comments

@pjdicke
Copy link

pjdicke commented May 3, 2016

I want the messages to be sticky and this works fine when developing but when I run ember build --environment production the prod version isn't sticky.

  flashMessageDefaults: {
     sticky: true,
     preventDuplicates: true
  }

I'm not overwriting this config anywhere else.

@poteto
Copy link
Collaborator

poteto commented May 3, 2016

Could you verify that these defaults are being set in the production environment?

@pjdicke
Copy link
Author

pjdicke commented May 3, 2016

Here is my current config:

module.exports = function(environment) {
  var ENV = {
    contentSecurityPolicy: {
      'default-src': "'none'",
      'script-src': "'self' *",
      'font-src': "'self'",
      'connect-src': "'self' *",
      'img-src': "'self'",
      'style-src': "'self' *",
      'media-src': "'self'"
    },
    modulePrefix: 'clfs-app',
    environment: environment,
    baseURL: '/clweb/CLFSAdminNew/',
    rootURL: '/clweb/CLFSAdminNew/',
    locationType: 'hash',
    EmberENV: {
      FEATURES: {
        // Here you can enable experimental features on an ember canary build
        // e.g. 'with-controller': true
      }
    },
    flashMessageDefaults: {
      sticky: true,
      preventDuplicates: true
    },
    APP: {
      imgSrc : '/clweb/apps/clfs/assets/images/'
      // Here you can pass flags/options to your application instance
      // when it is created
    }
  };

  if (environment === 'development') {
    // ENV.APP.LOG_RESOLVER = true;
    // ENV.APP.LOG_ACTIVE_GENERATION = true;
    // ENV.APP.LOG_TRANSITIONS = true;
    // ENV.APP.LOG_TRANSITIONS_INTERNAL = true;
    // ENV.APP.LOG_VIEW_LOOKUPS = true;
    ENV.APP.imgSrc = 'assets/images/';
  }

  if (environment === 'test') {
    // Testem prefers this...
    ENV.baseURL = '/';
    ENV.locationType = 'none';

    // keep test console output quieter
    ENV.APP.LOG_ACTIVE_GENERATION = false;
    ENV.APP.LOG_VIEW_LOOKUPS = false;

    ENV.APP.rootElement = '#ember-testing';
  }

  if (environment === 'production') {
    ENV.baseURL = '/clweb/CLFSAdminNew/';
  }

  return ENV;
};

I have tried the following for production:

  if (environment === 'production') {
    ENV.baseURL = '/clweb/CLFSAdminNew/';
    ENV.flashMessageDefaults = {
      sticky: true,
      preventDuplicates: true
    };
  }

No dice.

@poteto
Copy link
Collaborator

poteto commented May 3, 2016

Thanks for the detailed response! That's very odd, I don't do any environment checking in this addon. Could you please show me what the properties defined on your service looks like? If you open the ember-inspector in the production app you should be able to see something like this in the Container > service > flash-messages panel:

screenshot 2016-05-03 12 26 15

@pjdicke
Copy link
Author

pjdicke commented May 3, 2016

From production env/mode.

screen shot 2016-05-03 at 12 50 30 pm

@jcowley
Copy link

jcowley commented May 6, 2016

I don't think this has anything to do with the environment. I'm seeing sticky: true ignored in all environments.

@jcowley
Copy link

jcowley commented May 6, 2016

And, of course, as soon as I posted that it started working in all environments. Never mind. sigh

@pjdicke
Copy link
Author

pjdicke commented May 6, 2016

It only gets picked up when running ember serve but not for builds in my case.

@pjdicke
Copy link
Author

pjdicke commented May 6, 2016

Do you see anything that I might be doing wrong?

@pjdicke
Copy link
Author

pjdicke commented Jul 8, 2016

It's been awhile and figured I would check in on this issue. Any progress on wiring up the configuration overwrites correctly? I just had to do a new build on a new machine which pulled down a new copy of your addon which obviously wouldn't have my "hack" fix in the addonDefaults config obj.

@ajelinek
Copy link

I have been having the same issue. Once I think it works, it breaks again… Warning type was working fine, just not error.

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

No branches or pull requests

4 participants