-
Notifications
You must be signed in to change notification settings - Fork 28
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
Allow fullPaths to be configurable from the consuming app #108
Conversation
This doesn't account for the fact that I'm closing this PR because I don't want to try to land any other changes before the reimagining is complete but I'm leaving open the issue. Sound reasonable? |
@nathanhammond yeah fair enough, I charged headlong into the naive fix (time from GH issue to PR = 8 mins), so I'm happy to defer completely to the maintainers. My issue sprung up around a potentially-related problem, and configuring The crashes occur when |
is there a reason why don't just always specify fullPaths to false? |
Yes, it's because browserify doesn't correctly do incremental rebuilds when fullPaths is false. It's a performance optimization for working in development. This is why we only default |
Perhaps we could take the reverse approach, hardcoding This would support arbitrary environments with |
@timiyay that is a misunderstanding of how ember-cli handles qa, staging, and production environments are all Attempting to extend ember-cli's list of environments beyond development/test/production is not supported and likely to break. |
Ah righto, I'll need to review our environment / deploy practices for supporting a Our setup is based on a late-2015 recommendation from |
This PR solves the lack of configurability of
fullPaths
to support other production-like deployment environments, likestaging
.See #107