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

'preprocessCss' not respecting EmberApp's name same as 'preprocessJs' #827

Closed
bockscar opened this issue May 27, 2014 · 2 comments · Fixed by #955
Closed

'preprocessCss' not respecting EmberApp's name same as 'preprocessJs' #827

bockscar opened this issue May 27, 2014 · 2 comments · Fixed by #955
Labels

Comments

@bockscar
Copy link

New to ember-cli and not yet acquainted with codebase. Pull request would've been nice, but I couldn't figure out how to get to info I needed.

With an app set up something like this:

var app = new EmberApp({ name: 'ArbitraryNameFred' });

I would expect built assets named ArbitraryNameFred.js and ArbitraryNameFred.css.

The former file is named in abidance of the name key per app instantiation. However the latter defers to the package.json name and not the app's instantiated name.

This happens in preprocessCss which builds the path via 'assets/' + pkg.name + '.css' wherein pkg is package.json. The complication arises when multiple calls to preprocessCss are made but the output filename is different than the Javascript filename output.

This seems like it should be an easy fix, but I am not seeing where the EmberApp object is accessible from preprocessCss...so maybe it is not so easy.

Or perhaps this is the desired behavior, i.e., wired into package.json. Hopefully that is not the case as it greatly reduces flexibility. But if so, it'd probably reduce confusion if Javascript output abided by same convention.

Look forward to getting in more pull requests as I gain familiarity with this setup....

@stefanpenner
Copy link
Contributor

this may be fixed on master

@bockscar
Copy link
Author

Nah, master still references "pkg.name" as described above. Situation unchanged.

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.

2 participants