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

ESNext webpack via au build not using aurelia_project.environments file values #1077

Open
ajoslin103 opened this issue Mar 25, 2019 · 6 comments

Comments

@ajoslin103
Copy link

I'm submitting a bug report

au --version
1.0.0-beta.6

OS X 10.14.3

node -v
v10.14.0

npm -v
6.7.0

ESNext & Webpack

When I specify different values for baseUrl in my aurelia_project environment files they are NOT propagated into the .../dist/index.js file (via the index.ejs template)

When I add some commenting I can see that the aurelia environment files values have not been imported into the HtmlWebpackPlugin metadata area -- since they are referenced directly from the module export in webpack.config.js it seems too late to do anything about that...

How can I get the dist index.js to use values from the aurelia_project environment files ?

@3cp
Copy link
Member

3cp commented Mar 25, 2019

The env file is copied from aurelia_project/environments/name.js to src/environment.js everytime when you run au build or au run. It can be used in any source file.

For example the src/main.js uses it like this import environment from './environment';. Use those values in your code, you don't need to touch webpack config.

@ajoslin103
Copy link
Author

ajoslin103 commented Mar 26, 2019 via email

@3cp
Copy link
Member

3cp commented Mar 27, 2019

The baseUrl is directly written in your webpack.config.js

const baseUrl = '/';
// ...
  new HtmlWebpackPlugin({
      template: 'index.ejs',
      metadata: {
        // available in index.ejs //
        title, server, baseUrl
      }
    }),

@3cp
Copy link
Member

3cp commented Mar 27, 2019

If you wonder about this line in webpack.config.js.

module.exports = ({ production, server, extractCss, coverage, analyze, karma } = {}) => ({

It was called by aurelia_project/tasks/run

import {config} from './build';
//...
  const compiler = webpack(config);

The config in aurelia_project/tasks/build

const production = CLIOptions.getEnvironment() === 'prod';
const server = buildOptions.isApplicable('server');
const extractCss = buildOptions.isApplicable('extractCss');
const coverage = buildOptions.isApplicable('coverage');

const config = webpackConfig({
  production, server, extractCss, coverage, analyze
});

It means you can
control production with au run --env prod
control server, extractCss, coverage in aurelia_project/aurelia.json "build.options" (which enable option based on environment).
"extractCss": "prod" means true for production build, false for everything else.

@3cp
Copy link
Member

3cp commented Mar 27, 2019

I agree this is overly complicated, I prefer those options were directly written in webpack.config.js instead of jumping through 4 files.

@ajoslin103
Copy link
Author

Yes, in another project I went through the rigamarole of changing the params to the module.exports = ({ production, server, ... in the webpack.config.js file and then changing the params that it was called with from build and run...

I was hoping that someone had a better solution. Something that wan't so project-specific and involved changing so many files that are delivered by: au new

I would rather they were not written into webpack.config.js as they are then in two places. They belong in the environments files. They should be propagated from those into whatever config files are being used for whatever build tools are being executed.

I don't know enough to do all that, and only need the baseUrl right now -- but I have to keep re-writing that between dev/stage/prod when it's in the webpack.config.js

If I knew more about how it all worked I'd be able to put the contents of the selected environment file into the htmlWebpackPlugin.options.metadata and then have everything else source from there

that would be generic enough to satisfy my peculiar tastes

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

2 participants