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

Design and implement a unified environment config solution #2040

Open
mansona opened this issue Jul 11, 2024 · 0 comments
Open

Design and implement a unified environment config solution #2040

mansona opened this issue Jul 11, 2024 · 0 comments

Comments

@mansona
Copy link
Member

mansona commented Jul 11, 2024

There are 2 problems in the system right now:

  • we have dropped support for anyone using storeConfigInMeta: false
  • the config module that the app uses isn't where we have stored any of your config, we still have a node-land config outside of the app folder that represents the "old way" to do things

Ideally we would have only one concept for the config module, a simple ES module in your app that exports an object. But there are some challenges:

  • If we move the config into the ES module then the default behaviour of storeConfigInMeta: true will no longer work because we generate the config for the index.html in the content-for code in stage 1 (or 2 🤷)
  • we need to make sure that we can still provide a good API for people setting different config in different environments. We could do this with macros but that could prove difficult if we're overlaying babel based macros into a system that need to be automatically read to generate the index.html config meta

Possible solutions

This is not an exhaustive list so if anyone reading this comes up with other possible solutions please feel free to add them

  • if there is a timing issue with stage 1/2 having to read things from the config we could just divorce the implementation of StoreConfigInMeta from the Ember pre-build
  • it is possible that we could implement the whole concept as a vite/rollup plugin that other people could use outside of the ember ecosystem. With that in mind it's worth checking if there are already pre-existing solutions to what we're trying to do here

Example

here is a possible way to use macros to define the module:

import { macroCondition, isTesting } from '@embroider/macros';

  const ENV = {
    modulePrefix: 'app-template',
    environment,
    rootURL: '/',
    locationType: 'history',
    EmberENV: {
      EXTEND_PROTOTYPES: false,
      FEATURES: {
        // Here you can enable experimental features on an ember canary build
        // e.g. EMBER_NATIVE_DECORATOR_SUPPORT: true
      },
    },

    APP: {
      // Here you can pass flags/options to your application instance
      // when it is created
    },
  };

  if (macroCondition(isTesting())) {
    // Testem prefers this...
    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';
    ENV.APP.autoboot = false;
  }

  export default ENV;
@mansona mansona converted this from a draft issue Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

1 participant