Archive of RFCs for changes to ember-cli (for current RFC repo see https://github.com/emberjs/rfcs)
This repo is archived. The Ember CLI RFC process has merged into emberjs/rfcs. To read more about the move, see Ember RFC #300.
The suggestion is to change the auto-generated unit-test cases from something like this...
// Replace this with your real tests.
test('it exists', function(assert) {
var service = this.subject();
assert.ok(service);
});
...to this...
test('it exists', function(assert) {
var service = this.subject();
assert.ok(false,'The service "my-service" has not yet been tested. It is highly recommended that you test your code for reasons X,Y,Z...');
});
I originally posted this as an ember-cli issue. It was promptly closed. The comment was "generators producing failing tests by default is not something we will do, this will great excess pain/noise, with little rewards."
Although the issue was closed on ember-cli because it apparently didn't belong there (it rather belongs here), I found the comment above interesting. Particularly, I have to say that it didn't convince me because it wasn't clear. In what circumstances would such a change cause great excess pain/noise? Are the benefits I mentioned in the original post not rewarding enough in comparison?
Some factors I can think of that might have played a part in the decision:
I'm hoping for an elaboration or discussion of the above comment, because my personal experience tells me that the weighting is in the other direction (i.e. having failing tests by default would do more good than harm for the end quality of an app).
Sure, testing is one of those "delayed gratification" things that is painful at the start, and sure, the ignorant may be vociferous, but: Ember's supposed to be an opinionated framework, so here I am offering an opinion: such behavior is for me a clear fit to the "convention over configuration" mantra that makes us all love Ember. Convince me (and yourselves) otherwise.
npm allows the developer to determine whether to save a dependency in package.json under devDependencies or dependencies.
The difference between the two is that dependencies are required to run, while devDependencies are required to develop.
Examples of dependencies required to run: ember-cli, ember-resolver, and ember-core.
Examples of devDependencies required to develop: ember-cli, ember-resolver, ember-core, ember-cli-template-lint, ember-cli-jshint, and ember-cli-qunit.
In an Ember app, a user would have to manually maintain dependencies in package.json when running ember install <addon>.
I propose a --dev flag to ember install to allow developers to decide when the addon is not for development, like ember-route-action-helper, which would be used in-app. The flag would be true by default.
A benefit to this is that addons that are truly devDependencies would be excluded when the repo is being built and deployed in a CI environment, thus speeding up the process.
Access to the build-time configuration (app.options) is inconsistent between the public hooks in an addon. For instance, this.app is undefined inside of setupPreprocessorRegistry but not inside of included.
This inconsistency makes things that should be straightforward more difficult. To illustrate:
included: function (app) {
console.log('included', !!this.app);
}
setupPreprocessorRegistry: function(type, registry) {
console.log('setupPreprocessorRegistry', !!this.app);
}
Logs the following:
setupPreprocessorRegistry false
setupPreprocessorRegistry false
included true
However, the app is actually available if you look in the "right" place:
setupPreprocessorRegistry: function(type, registry) {
console.log('setupPreprocessorRegistry', type, !!registry.app);
}
Logs:
setupPreprocessorRegistry self true
setupPreprocessorRegistry parent true
So it is clear that the information is available before included is called, it just isn't exposed to the addon directly. There are ways to work around it -- for instance by stashing the parent's registry and then using it inside of included to add preprocessors -- but then what is the point of having a separate hook?
Another workaround is to put all this configuration inside of environment.js and then accessing it via the project config. This is even worse because all of that stuff ends up in the client when it is only needed at build time. This is just terrible, but many people do it.
There are definitely valid use cases for reading the build configuration from within setupPreprocessorRegistry, namely:
Ultimately, this particular flaw causes developers to introduce temporal coupling into their addon by ensuring that parts of their code only run after included in order to assure this.app is a thing. This is bad, and unnecessary since it can be proven that the information is already there to begin with.
I would like to make dummy apps less of a special case. Right now they have some weird behaviors, like:
project.root directory points at the true root of the addon repo, which is not the root of the dummy app itself. There is a Known Hack™️ for reliably getting the real app root like path.join(project.configPath(), '../..'), since configPath does point at the right place for dummy apps. Due to this special case, many addons don't work correctly when you try to consume them inside a dummy app.tests/acceptance implicitly run against the dummy app, which makes them different from what an app developer has come to expect. Now, obviously there is no other place for them to run against, but this is still a bit jarring when first encountered.ember-cli/lib/broccoli/ember-addon exists to build dummy apps, not addons (which makes its name confusing), and the only reason it needs to exist at all is that dummy apps are doing all these weird things.dummy is not a great name and we can come up with something more descriptive. Candidates include sample-app or test-harness-app.The general shape of my proposal is:
move ./tests/dummy to ./sample-app or whatever other name we bikeshed as a good default one.
the root ember-cli-build.js would change to mostly delegating to ./sample-app/ember-cli-build.js, in order to make it clear that there's no app config that lives at the root level.
./sample-app/ember-cli-build.js would import ember-cli/lib/broccoli/ember-app, not ember-cli/lib/broccoli/ember-addon (which would get deprecated)
dummy apps would become 100% normal ember apps. They should have their own package.json (like ./sample-app/package.json), and you should be able to cd ./sample-app && ember s and everything works exactly as it would if you were in a normal standalone app. They can have the stock app .eslintrc.js in their own directory, meaning no special lint rules are required.
our previous work on fixing node_modules resolution means that a normal ember app located in ./sample-app is still able to access all the dependencies in ./node_modules, so no special casing is required there. This also allows multiple dummy apps to choose to include only subsets of their parent addon's devDependencies just by not including them in the dummy app's package.json (this is already how ember-cli works -- no special cases for dummy apps).
acceptance tests should live inside the app that they are testing. So today's ./tests/acceptance would move to ./sample-app/tests/acceptance. This makes them conform exactly to what app developers already know about acceptance tests.
./tests/unit and ./tests/integration can stay where they are, those test suites can (in principle) run even if you choose to have no dummy app at all.
The only chunk of API design that I see missing from the above is deciding in detail what to put into the top-level ember-cli-build such that you can conveniently
ember s process.A totally strawman example of the new top-level ember-cli-build.js would look like:
const AddonDevSetup = require('ember-cli/addon-dev-setup');
module.exports = new AddonDevSetup({
sampleApps: [
{
// the app we're loading
app: require('./sample-app/ember-cli-build.js'),
// where to mount the app in the ember development server. Could
// potentially allow seting to `null` if you don't want the app to start
// automatically when you do a top-level `ember s`.
rootURL: '/'
// whether to run this app's `ember test` when we do a top-level `ember test`
includeTests: true
}
]
});seems to be coming up from time to time, seems like we could quite easily support it. Obviously needs fleshing out.
In an addon I can look in project.packageInfoCache.entries and see all of the installed packages at app build time, but as @Turbo87 mentions in ivanvanderbyl/ember-d3#69 (review) this doesn't appear to be public.
In addons like ember-d3 or @fortawesome/ember-fontawesome where it is important to validate or transform packages at build time this is needed functionality.
The private method https://ember-cli.com/api/classes/Project.html#method_dependencies exposes this, but only at the level of the application not the deep tree present in project.packageInfoCache.entries.
Many 3rd part libraries that aren't ember-addons provide es6 versions of their modules. At the moment, consuming these is hard without a shim-addon + custom broccoli-funnel+babel or using something like ember-rollup.
I believe this is something we should make "just work".
Ember CLI currently has a quite high startup time due to the over 2000 require() calls and potentially more in every addon and blueprint in the projects. Gradle in the Java world had roughly similar problems and solved them by using a long-lived daemon process that is controlled by their gradle CLI tool.
Speeding up the startup time is required for things like #23 but I admit that I'm not sure yet if the added complexity is worth it. It would likely need to have a few more advantages to justify it. #4 might also be related to this idea.
I would like to create a library that is pure JS at its core, but is consumable as an Ember addon. I can use the main option in package.json to specify an entry point other than index.js, but that entry-point is both for pure-JS (e.g. node) consumption and Ember-CLI consumption.
As teams grow, it is often helpful to extract code from one application into a shared library. It's easy to do that as an Ember addon. But not all teams and projects use Ember.
Currently, the "standard" solution is to have two packages: @my-org/foo and @my-org/ember-foo. The former contains the business logic of the addon. The latter contains little more than an index.js with some Broccoli tree management to support import foo from '@my-org/foo' in an Ember application. The extra package means more time managing dependencies.
It would be much easier to maintain a single package that is usable without ember, but which knows how to package itself for ember.
// package.json
"ember-addon": {
"main": "lib/ember-addon.js"
},
"optionalDependencies": {
// things lib/ember-addon.js uses directly:
"broccoli-merge-trees": "^2.0.0 || ^3.0.0",
"ember-cli-babel": ">= 6.0.0",
// ember compatibility:
"ember-source": "^2.8.0 || ^3.0.0"
}We need an RFC for the migration plan off of bower. This RFC should address:
Possible approaches:
Notes:
The existing lib/broccoli/ember-app has a lot of organically grown behavior which supports our needs at present but doesn't give us as many opportunities to grow for the future. We're going to need to do some work in this area to support the new module unification RFC and this gives us as good a reason as any to ensure that we start this process off on a good footing.
A lot of these pain points have been discovered in the development efforts for FastBoot and Ember Engines and last year's efforts toward a linker/packager.
noConflict story for globals code included in nested addons.Is this a complete enumeration of our goals? What else do we need to address in this effort?
/cc @chadhietala @danmcclain @dgeb @lukemelia @rwjblue @stefanpenner @tomdale @Turbo87 @twokul
Today, if you would like to add a command you must add an in-repo addon that implements the includedCommands method.
Contrast this with the ease of making a built-in blueprint: simply place a file in blueprints/some-name/index.js and 💥 everything works.
This issue is mostly to gauge interest in supporting auto-detection of project and addon commands by way of a specific location on disk (e.g. <project-root>/commands or <project-root>/lib/commands)...
👍 / 👎 ?
We should make it possible for blueprints to support introspecting state and application, and investigate something similar to lifecycle hooks.
This would support things like:
ember init....and more.
This has a number of use cases, but I'll list just a couple:
chalk.red colored output).chalk to opt out of colored output (resulting in bizarro text output).Suggestions:
.ember-cli file. I believe this is possible but it needs research.--no-color command line flag on all commands (this is already supported by way of https://github.com/chalk/supports-color, but isn't documented at all)These are things that are very much broken but we can't change for reasons of backwards compatibility. This list is for a very specific category of issue. These should tend toward mechanical changes.
When you comment on this thread please identify why your issue fits this category. The canonical list will be hoisted here. Comments will only be used to identify which things should be promoted to this top post.
vendor-prefix.js.deprecateUI (Standard deprecation removal.)We should come up with a default story for a ServiceWorker, beyond just a simple application shell and the toolbox strategies. We need to draft an RFC that describes a complete implementation inside of ember-cli, specified well enough that it can be implemented by anybody.
This issue will be updated after the face-to-face and exists for collecting thoughts. @nathanhammond will serialize earlier conversations into this thread, no need to try and reproduce that information.
I'd like to add directories (that contain some magic used by an addon) to the watcher, so that changed files trigger a server restart (like app, tests etc.). Ideally this could be done by said addon through a hook.
Use case: I use this to provide some extended version of mocks (like server directory, only in a different directory).
This was originally reported as ember-cli/ember-cli#4717.
With all the new modularization happening I'd like to champion swapping Broccoli out for Webpack in Ember CLI.
Without writing a big wall of text, here's my short outline of why:
TL;DR I think it is time to admit Broccoli is a dead end street and that Webpack will bring more benefits to Ember.
Maybe https://github.com/trabus/ember-cli-rename could become part of the ember-cli core?
We run ember-cli within a Docker container for development. (This issue is less meaningful for Dockerized Ember FastBoot running in production.)
Standard Docker practice is to have a container that
node and watchman installedNormally, this might look something like
$ docker run -v "/Users/me/code/my-app:/www/my-app"The problem with that mount is that it also syncs /Users/me/code/my-app/tmp/**/*.*, which can be very expensive. That's because Docker waits for all syncs to happen before triggering the file-system event(s). In our tests, the time between saving a single file and ember-cli starting a rebuild is 30 seconds, up from less than a second when we exclude my-app/tmp.
Unfortunately, there's no syntax in Docker for excluding a particular subdirectory, so we end up mounting parts of the app individually:
$ docker run \
-v "/Users/me/code/my-app/app:/www/my-app/app" \
-v "/Users/me/code/my-app/config:/www/my-app/config" \
-v "/Users/me/code/my-app/package.json:/www/my-app/package.json" \
-v "/Users/me/code/my-app/tests:/www/my-app/tests"
...It would be lovely if we could configure ember-cli's tmp directory to be e.g. /tmp so that it's not part of the mount.
We can do this for broccoli addons that extend broccoli-persistent-filter by setting BROCCOLI_PERSISTENT_FILTER_CACHE_ROOT, but that's far from everything that an ember-cli application puts in ./tmp.
There is currently no clean way to skip the import of assets triggered by an ember-cli addon from inside the ember app.
In some cases files can be removed by passing a broccoli Funnel to app.toTree() or post-processing the generated tree using a funnel.
However this doesn't work for the very common case, where an ember-cli addon adds a default style, for example from a wrapped bower package, because all css is already concatenated into addons.css when we get the change to process the tree.
It would be great if ember-cli provided a funnel that gets executed before any concatenation or preprocessing of imported trees is done, which could then be used to exclude (or include) additional files using the patterns provided by broccoli-funnel.
Example:
The addon ember-foo wraps the bower package foo and imports its assets in the included() hook:
module.exports = {
name: 'ember-foo',
included: function(app) {
app.import(app.bowerDirectory + '/foo/foo.js');
app.import(app.bowerDirectory + '/foo/foo.css');
}
};We do not need the file foo.cssbecause we have provided our own styles and overriding the existing styles would be cumbersome, so it would be great if we could exclude it in ember-cli-build.js:
var app = new EmberApp(defaults, {
filterAddonTree: {
exclude: ['bower_components/foo/foo.css']
}
});In a similar fashion it is also possible, that a bower component has multiple variants and we want to exclude: ['bower_components/foo/foo-deluxe.js'] and include: ['bower_components/foo/foo-light.js'] because it is sufficient for our needs.
Both of the above mentioned examples could be solved by adding additional configuration to the ember-foo addon, but it would be great if there was a simple way to solve such a common issue without having to modify the addon to provide every possible permutation of assets.
Currently both autoprefixer and babel can take a browser support params which determine what kind of polyfills need to be included.
I think it could be useful to have browserSupport property by default in config.js which could then be read both by babel and autoprefixer.
Potentionally even Ember-CLI could then filter out certain code based on the browser support (Ember.RSVP ?).
While RFC #95 allows efficient transpilation and targeting modern JS engines, flaws appear when actually applying this.
I have 2 concrete issues, which both occurs when targeting modern browsers that allow ES6 features.
The first major issue is minification: The currently used UglifyJS does not support ES6 syntax and throws arcane errors when trying to produce a minified build. This can be somewhat alleviated by using ember-cli-babili, which supports such syntax. However, there are 2 specific reasons why this works: First, it only applies ES5-safe transforms. To do anything else, it would need to take into account the full browser matrix. Secondly, it uses the babel engine, ensuring syntax compatibility. Without this, it will break when new syntax elements are introduced to the language.
The second issue is testing: Currently PhantomJS is used, which again does not support ES6 syntax. This has a quick fix (add a PhantomJS compatible browser to the targets when testing), but this somewhat undermines the actual testing.
Even if this was replaced with a more compatible JS engine, there is no guarantee that it would match the targets that the user has specified, and will thus always require a test-specific transpilation target (which again undermines the validity).
With these 2 issues I think that the targets RFC actually ends up doing more harm than good. It is great to leverage the tremendous effort that has been put into creating these browser targets, but not so great when the supporting eco-system has to do a comparable effort to support this, and we have a deep vendor lock-in.
TDLR: The targets needs to respected at 3 tiers of JS, rather than just the one that was intended, which greatly complicates the eco-system.
I've been thinking a lot about what differentiates us (good and bad) from the rest of the JS ecosystem lately, and I think I've come to a conclusion that should perhaps be turned into a point of action.
It's been stated by others (and I agree) that much of the future of Ember is in ember-cli.
But as good as ember-cli and broccoli are, I feel we are losing pace against the rest of the ecosystem on features we've wanted to have.
For some, this manifests as the pestering question of "why not WebPack", such as in #79
So I set out to explore a bit of WebPack, and found (unsurprisingly) that it doesn't offer us much, but would be nice if they pivot to being a more generic bundler (which they seem willing to do based on discussions with @TheLarkInn), in which case it may offer us an easier bundle optimization story.
My conclusion though is that where we are losing pace is in the bundle integration and configuration story. Things like webworker/service worker integration, apps shell, PWAs/IWAs, code splitting, tree shaking etc.
Basically, we ignored the bundle step while focusing on other major ticket items that also matter. The problem with this is that there are many in our ecosystem willing to make stabs at this story, explore it, and maybe even land it either as an RFC or as an addon, but they haven't been empowered.
WebPack is empowering because despite limitations on APIs, and a terrible (imao) configuration story and dependency model, it is well documented, provides clear examples, and its core team actively and aggressively helps anyone and everyone learn how to use it better.
I think this underscores the importance of documentation, examples and hands on experience/tutorials, which are almost entirely missing for broccoli and ember-cli.
We have a great community, let's use it. To use it, we need to empower them, and all it would take to do so I think is giving a little time each day or week to teach, document, or write an example of something you can do with ember-cli, broccoli, handlebars/babel ASTs, babel configuration and plugins, ember-rollup and the like.
I often find that when I feel I need to do it all, I've simply failed to communicate the problem space adequately to others. I feel many of us feel that "we've got to do it all". If we teach our stack, and offload our domain knowledge of what we are looking for in a bundler / static build time tools etc, better things may arise without us needing to do it all, and everyone will be happier and our involved community will grow even more.
This doesn't mean we brain dump in more RFCs (although we should), because I suspect the RFC audience is a bit too narrow. It probably means we brain dump in RFCs + a blog post + push those materials out as "help wanted". I see @gaearon and others doing this often to great success. I feel we usually just ask for comments, not help, and that gives the wrong impression that we have all the needed man power to accomplish all the things we want quickly.
Even where we have documented ember-cli, that documentation is often hard to find, surface, or relate to the problem attempting to be solved by the end user. Documentation isn’t real unless its easy to surface and understand. "Help Wanted" labels on Github are useful, but often fall silent if we don't also publicize the desire for help.
Lets begin this discussion.
What is ember-fetch?
Why is this discussion happening now and not earlier?
Cons:
$.ajaxPrefilter are not obviously a thing in fetch (maybe some other approach ?)Noop:
things to check:
Hi,
when generating a new ember-app the cli will create a reasonable starting-structure and default .gitignore.
There are pre-populated and empty folders in that structure, depending on how much sense it makes for those folders.
One folder that is not currently created by default and also ignored, is the distfolder. Although it makes sense to ignore the contents of the dist-folder, I would like to argue for the idea that the folder itself belongs to an ember-project:
mkdir dist either by hand or from within the build-chain. To prevent having the contributors creating the dir before they can run things like 'cordova prepare', one might have the idea to checkin the dist-folder into git and then ignore just it's contents via a .gitignore inside it. But since ember build will delete the contents of dist, that gitignore will also be deleted.Babel knows about the runtime helpers that are required and we should generate an optimal set of helpers for Ember apps.
CH - We should generate babel helpers at build time and externalize them
SP - Seems good, but we should create a whitelist of helpers used today so that we can some idea of the runtime costs. It should throw when it encounters a runtime helper not listed and we can just provide our own helpers.
CH - Will work on that today (See babel/broccoli-babel-transpiler#96 and babel/broccoli-babel-transpiler#95)
SP - Please write an issue on the ember-cli/rfcs repo so we can come back to this.
This issue is for collecting examples of extending or subverting ember-cli EmberApp, commands, tasks, and models inside of the addon ecosystem. Please add one comment per example, as well as a brief note about what it appears to be trying to accomplish.
/cc @lukemelia @achambers @stefanpenner @kellyselden @runspired @trabus @Turbo87 @kategengler @chadhietala @trentmwillis @rwjblue
Start Date: 2016-11-23
RFC PR: (leave this empty)
Ember CLI Issue: (leave this empty)
Add the ability for ember serve and ember test --server to watch additional files that are not necessarily parsed by broccoli, but potentially used in the build. Originally requested here: #25, but not fully flushed out. Primary use would be to allow files in server and test to trigger full restart, and trigger either a rebuild or provide a hook to re-run node tests when these files change.
I use the server directory in both dev and prod (via a prod express server located in the root), and as such, have some application-server logic that I test with tests in the test folder.
As per detailed in ember-cli-code-coverage/ember-cli-code-coverage#79, I run pre and post build tests & coverage for my server code when running tests, but according to ember-cli/ember-cli#4717, currently ember-cli does not support adding arbitrary paths to the watcher, which means that when I run ember test --server, the tests will not re-run when editing server tests or files.
In addition, I've noticed some idiosyncrasies when using the server folder as a first-class citizen in this build setup, namely that the server does not perform a full restart when changing files (which can lead to cached server modules). This may be an unrelated RFC candidate, but it seems like they are in the same ballpark so may be worth looking at during this work.
The following changes would be required:
server, application server tests in test)At it's most basic, this feature would simply add a new config key to .ember-cli, that would enable rebuild/restart on paths outside of the broccoli tree.
At it's most complicated, this feature would modify ember-cli to:
Ember already supports a fairly robust application server setup, which I've been working on taking advantage of for automatic API generation over at https://github.com/jesseditson/ember-jsonapi.
This change would primarily be a functional change, but would also open up the possibility of bringing the server folder in to the docs a bit more, primarily around how to properly test the files in that folder, and clarification around expected rebuild functionality for files outside of the broccoli tree.
I believe this RFC is in the spirit of existing ember-cli conventions, and as such proposes no changes to terminology or patterns, save for potentially defining a standard path to testing server code.
This could potentially broaden the scope of ember-cli, which seems worth taking very seriously from a support perspective. The server folder seems like an afterthought, and this could potentially legitimize it's use, which may not be in the interests of the maintainers.
As far as I can tell, this isn't currently directly achievable using the ember-cli watchers as they are set up today, otherwise I'd be exploring an addon solution for this.
Currently I solve for half of this issue this by running a docker-compose setup which runs a proxy back to my host machine's port 4200 and maintains a separate watcher process for server code. This means the server could get out of sync when restarting (as changing shared files would cause both a server and ember restart/rebuild), so I put a default nginx page that polls the host machine for the ember server, and reloads when it comes online. I think this could be greatly simplified by giving the ember server folder some love.
I don't currently have a solution for reloading the server tests when they are modified (or when the server files are modified), but I suspect a workaround would require adding an additional watcher process (I could see something like parallelizing a subprocess running watchman using an addon hook, but this has plenty of drawbacks).
Mainly I'd like to get the temperature of the room on the intended use of server. Am I opening a pandora's box of support issues if ember starts supporting an application server? On the flip side, I think minimal support on ember-cli's part would open up a good ecosystem of addons that leverage the node layer, which would allow us to share config across the client and application server (this has been very useful for me when sharing models across the stack).
Clarity necessary before action: Is this RFC best suited for a deep-dive on the server process and how it is watched, or is this RFC "simply" a modification to the available options and/or defaults of the ember-cli test watcher?
Currently, all tree paths (app, tests, vendor, etc.) are static and cannot be configured.
I'd like to propose adding inputPaths to the EmberApp options hash allowing them to be optionally configured.
const app = new EmberApp(defaults, {
inputPaths: {
vendor: 'statics/vendor',
public: 'statics/public',
// etc..
}
});Unsure if this is a large enough change to warrant an RFC or not. Happy to PR this if it's something that has buy in.
Hey, first of all if this has been discussed anywhere before just point me to it, I didn't find any topic like this anywhere.
So this is just a thought I've been having for some time now, but what would the general consensus be with regards to removing ember data from the default ember-cli blueprints?
It seems to me that this would give us a big benefit in terms of significantly less overhead for newcomers (if we also move ED out of the tutorial/guides and into a separate "advanced" or "managing data" section) while practically speaking being a non-issue for advanced people (one ember install away from adding it).
Are there some big issues I'm missing? It seems to me like removing it would be of more value then leaving it in. I would like to see more people adopting Ember, but I feel like our onboarding process has much room for improvement. This way would be a quick (and unless I'm missing something pretty painless) way to shed much of the perceived weight of Ember without impacting experienced users.
👍 / 👎 / 
?
some thoughts, leaving them here for future travelers
There is a constant request to expand the number of environment one can use. Although this is perfectly reasonable and internals should (and will support this). I have noticed another similar trend, build targets
Ideally, I would like to not see dev_cordova prod_cordova test_corvoda, dev_electron,prod_electron etc.etc. As this quickly becomes entirely unmanageable and the cost of adding a new target becomes quite large. It also becomes tricky when dealing with addons, that maybe only need to do something in testing of Cordova.
One thought I had, was to split the concept into target and type.
webenvironment – in-fact it may make sense just to call it environment. : defaults to devember build --target electron --type test
ember server --target electron --type test
ember test --target electron
ember test --target electron --serverThis could allow us to provide stable public CLI interface, addon hooks, and should help become a good foundation for future innovation.
stuff to explore
cc people who have been doing related work (based on emberaddons.com search): @mike-north @poteto @rwjblue @jakecraige @juanazam @theodorton @brzpegasus @rmachielse
ember g license <license-type=MIT>? Makes it relatively straightforward to toggle off and on, simple to chain to a previous blueprint, provides a choke point for the configuration. And then we can start to make it configurable.
Slightly odd ember d license invocation: it doesn't matter what the type so it doesn't have to be parallel with the generate command.
That we assume a license at all is probably bad.
When generating a new package.json using npm init, the "repository" field automatically gets filled if the destination directory is a git repository and has a remote configured.
However, when runing ember init within a repo's directory, the "repository" field currently simply stays empty. Wouldn't it be great if ember-cli did the same thing?
Currently, npm isn't really doing a great job because it fills the field with an object containing several things like the type of the repo and the url:
"repository": {
"type": "git",
"url": "https://github.com/ember-cli/rfcs.git"
}However, the upper code isn't needed when it comes to GitHub repositories. Instead of that, ember-cli should do it like this (here are other shorthand examples for different providers):
"repository": "ember-cli/rfcs"In the spirit of independent components and the better organization of pods, I think that being able to save and run tests frompods will help to keep the file structure more organized.
One of our project goals is to separate build types (e.g. debug, production) from deployment targets (e.g. development, alpha, production). Ideally in our build phase we run all build types, then reuse those built artifacts for any given deployment target. Here are some benefits of this approach:
Here is a rough description of the build / deploy flow we want to implement:
Build:
ember build --environment $type.dist folder as a tar artifact.aws s3 cp $type.tar s3://my-app-builds/$commit/$type.tarDeploy:
ember target --folder dist --config production.jsonI was going to add this use case as a comment on #26, but it seemed different enough to warrant its own issue. The important difference is that this very deliberately doesn't require any changes in the build for a different target.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.