Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: use npm run instead of the donejs command #84
One of the things that first confused me when building a DoneJS app was that the special commands, like
Is there a reason why we specifically encourage commands like
@chasenlehara We do it for uniformity.
Sorry, I wasn’t clear in my original post; I’m not advocating for something like
For me, it makes sense to differentiate between the commands that are special to our CLI vs. npm. For example, we show installing Bootstrap with
I agree with @chasenlehara. When I first encountered
Bumping this now that npx is a thing and I think you can run generators through npm?
npx provides many of the same features that the donejs cli is used for. I'm not as familiar as some other people so I'd like to get their feedback. @BigAB @justinbmeyer have discussed the idea. Some of the commands we have:
I think that's it... can we provide all of this through
Also, what does this mean for yarn projects, or do we just only support npm?
referenced this issue
Jul 20, 2018
I don't know enough about
In the project though, if
There is also a new thing in
You can also use the scopes so you could do something like
With npx and npm offering these kinds of utilities, it's probably worth considering not only implementing these features, but maybe modifying our own donejs-cli api to be more friendly when using them.
tldr; Transition away from donejs-cli in favor of
This proposal seeks to deprecate the donejs cli and instead use the built-in features of npm (and possibly) yarn to generate and control donejs applications.
We designed the donejs cli so that it is only a thin layer around a project's package.json scripts and binaries installed within
Since the beginning we have had a problem with donejs apps taking a long time to install. We have improved this over time by deferring installing things until we need them, through generators such as
Since donejs was first released, npm and yarn have created ways to generate new projects without needing a special global cli. Additionally
This proposal seeks to do away with the donejs cli, and instead rely on npm/npx. This means that a basic donejs app could be installed with:
This will run create-donejs-app which will generate a new donejs app.
The initial package.json will look something like this:
Notice that we only install
It's likely we'll want a couple of more things, such as perhaps steal-qunit or another testing utilities. The point is that by default we only include what is minimally needed to get started.
When you want server-side rendering you can install done-serve using
This will install the
When you want testing perhaps you run something like:
When will install testee and another other needed utilities.
To generate a new component you can run:
Here donejs-add is a project that works the same way as our current
The goals here are:
I like the above but I would suggest:
The initial package.json will include a dev dependency of
So that way when you
Thanks @BigAB, the specifics are definitely something we can discuss, I just wanted to get the proposal ready for the survey. We could have
@justinbmeyer You might have missed it, but the proposal mentions that likely something like
Testee likely would not be included (it's one of the things that takes a long time to install), but there's less of a reason for Testee until you have CI.
Installing testee and ssr takes away from the idea of a having a lightweight way to use steal and canjs together. Another option I thought of is having a "light" mode or something that works like the above.
Would include basically everything that gets installed today. But if you did:
Would be the slimmed down version like shown above. I prefer the install-as-you-go approach because I think having 2 modes will be harder to maintain.
I would take it one step further than what @matthewp proposed.
I would actually make the default installation NOT include
Don't get wrong I 100% agree that SSR, and testing are important to an application, but they are furthest thing from my mind when I am developing a brand new application.
I care about one thing when starting a new application, and that is getting into writing my specific application code as soon as possible. This includes not being distracted by a whole bunch of other concepts (or code or files) that I am just not ready to deal with at the start of a new application.