Open kestred opened 5 years ago
All of this can be implemented with a plugin.
Plus I think the whole app structure needs to stay (just moved, maybe - to /example) since every lib needs some sort of demo to test live anyway.
I think that's need to consider bundler. In general, the library author also needs to be concerned about the code size to be bundled. vue-cli can currently only be supported with webpack. we cannot bundle with rollup.
Yeah I agree. Roll up is usually better suited to bundle smaller libraries.
I'm actually experimenting with roll up in a vue-cli project right now and plan to turn it into a cli plugin over the holidays if it works out well.
Definitely, I've used / had-success-with rollup
in the past--- do either of you have particular thoughts about how a rollup
option might be superior to the current Vue CLI Service's vue-cli-service build --target lib
?
Mostly smaller code-size output?
That would be mostly it, yes. Plus the ability to create a module that uses actual ESModule exports (esm
format).
From what I have tried so far, usually the vue-cli "app" becomes an example/demo application that I use to the the lib I write - for this, the dev server setup etc is still great. Also the test plugins etc are still 100% useful.
It's just the lib code that I would bundle with rollup.
@LinusBorg
I'm actually experimenting with roll up in a vue-cli project right now and plan to turn it into a cli plugin over the holidays if it works out well.
Have you already published the code on GitHub repo? I'm interested in your experimental code due to need to setup my project. :)
Edit:
I misread. I didn't get much done for the roll up plugin, but started a similar one that's focussed on setting up the project folder for building a lib/plugin.
Can share later, even though it's not fully working yet and not documented.
If you're more intersted in rollup, have a look at the setup I used for bulding portal-vue 2.0.0 (unreleased) here: https://github.com/LinusBorg/portal-vue/tree/next
Thank you very much! I'll try to check your project.
Not sure if this is the best issue to add to, but I tried using the cli support for building a library project for the first time, and found the whole experience to be awful. I'm not sure if changing that experience is a matter of better documentation or, as @kestred proposed, a better scaffold for library projects, but either way, I think there needs to be improvement here.
I was trying to build a library so that I could have a place to reuse components between several related vue projects. The first thing I wanted to do was have more than one component be accessible from the library. The next thing I wanted was an easy way to use the library locally, without having to publish either to npm or even a remote git repo. However, any of those options appear to require changes to the default generated project (changes to package.json for instance, a main entry, etc), and even after following the one tutorial I found online:
I still ran into errors trying to actually use the exported components from my library. I'm sure if I were better versed in the nuances of module formats and package creation maybe I could get it work, but that's kinda the point. I think it should be easy for any user to come along and at least have the generated library work with a cli generated project-
I had made MVP of Vue CLI plugin. The documentation is WIP, but you can try it. https://github.com/kazupon/vue-cli-plugin-p11n
As motivation, this Vue CLI plugin is making for my project (next vue-i18n) scaffolding, if you would like to feedback, I'll try to improve my Vue CLI plugin.
@kestred In my opinion, it's not necessary to support with Vue CLI itself, beause we can realize with Vue CLI plugin.
I'd like to echo @chriszrc comment, i just spent the weekend banging my head trying to get the cli's library output to work properly, and it was awful. I followed the same tutorial he came across, managing to get it to work properly with ES based projects, but couldn't get TS based project to work to save my life. I honestly can't tell if the library build target is fully functional or if i'm doing something wrong.
Luckily I found this issue and switched to using @kazupon 's plugin which made everything sooooo much easier. So thanks for that @kazupon ! There are a few issue with it right now, but overall it was a much easier experience, and I'd like to see something similar implemented in the CLI. If it's another plugin I think that's 100% fine in my book, but I feel like we should have an official option of some sort available for users starting library projects.
Any progress on this? came from https://github.com/vuejs/vue-cli/issues/1081
Updated: Dec 1, 2018 (per conservation)
What problem does this feature solve?
If someone is setting out to build a library with more than one component in it, there isn't a clear correct way to do so. Similarly, there are no best practices provided by the community to stay consistent (or just avoid having to make decisions yourself when rapidly prototyping).
A library option in
vue create
would create a project intended to be compiled and distributed as a Library/Plugin rather than an Application.Workflow Differences
A library project typically doesn't have an
App.vue
or anindex.html
, and this changes the way that you might want to develop the application. Notably,vue-cli-service serve
doesn't necessarily have anything "canonical" to serve.A few workflows that might be common:
demo
,test
, ordocs
website that renders the application (possibly usingvue-cli-service serve
).dist
, supported by auto re-build (something likevue-cli-service watch
?).Many library projects typically commit their
dist
by default (or at least as part of publishing) rather than ignoring it in.gitignore
.What does the proposed API look like?
A
vue create --target lib
orvue create --target plugin
would be added as a command line optionChanges to "Manually select features"
These feature options might be removed:
Changes to code generation
The
public
directory would not be generated.The
App.vue
file would not be generated.Instead of generating,
public
andApp.vue
, anexample
directory would be generated withindex.html
,main.{js,ts}
, andApp.vue
and a dependency on the library itself.package.json
vue create
to generate anexample
vsdocs
, or other testing website stub.A
lib.{js,ts}
file would be generated instead ofmain.{js,ts}
, perhaps something like (e.g. for Typescript)The
package.json
'sbuild
script would be replaced withvue-cli-service build --target lib --name MY_LIBRARY_NAME src/lib.ts
.The
package.json
would either not include aserve
script, or theserve
task/script would be updated to serve theexample
application for the library.The
yarn.lock
andpackage-lock.json
patterns would be added to the.gitignore
file.Additionally, any other code generation changes as appropriate according to community best practices.
Open Questions
vue-cli
andvue-cli-service
would be updated to supportrollup
rather than relying on the currentvue-cli-service build --target lib
.dist
directory would be removed from the.gitignore
by default.npm
) as a library?