Description
What problem does this feature solve?
I apologize. The previous issue had comments disabled as I was in the middle of responding to the comments by @sodatea and @yyx990803 . There is confusion that I'm trying to address. I'm talking about existing projects see my comment below. I think it's in the best interest and for increased adoption of Vue JS that a thorough discussion from both sides is had instead of ending it prematurely before I even had a chance to respond. I understand wanting to limit for new projects, but existing projects is where greater adoption for Vue JS is. It will also allow for existing projects to transition from another front end to Vue JS slowly without having to re-write an entire app. Businesses aren't going to spend a bunch of money upfront to rewrite an entire app. A slow transition is more feasible.
Feature
Having the Vue src files and directories in the /src directory works for simple projects, but for more complex projects it doesn't work as well. If you're including the Vuejs project in with another project with other programming languages that follow a different or same src dir causes problems. This feature will separate the vue code from the other project code (js/PHP/C#/Go/python/etc.)
Currently if you want to modify the vue src directory you need to modify vue.config.js:
- change the alias @ path.
configureWebpack: {
resolve: {
alias: {
'@': path.join(__dirname, vueSrc)
}
}
}
- Use the pages option to change their path:
pages: {
app_main: {
entry: path.join(vueSrc, 'main.ts'),
template: path.join(vueSrc, 'public/index.html'),
filename: 'index.html',
title: 'Index'
}
}
There might be other locations or properties that need to be updated with the change in src directory, but these 2 are the ones I've noticed so far.
There is the public directory that should also be considered. I assume it would also be moved into the specified Vue src directory or made into a separate web.config.js option.
If this is already doable without all the customization mentioned above, let me know.
What does the proposed API look like?
- Add an option to vue.config.js called
src
orvueSrc
orvueDir
orsrcDir
orvueSrcDir
orsourceDir
or whatever is deemed appropriate. - Either assume the public folder is also in the new vueSrc path or create a separate publicSrc (or publicDir) option in vue.config.js.
The value would be starting the current directory so you don't need to include the whole path.
Example: if you wanted to change the src vue directory and files from src to webclient/vue.
Note: The developer would manually create the new webclient directory in the project root. Then rename the src directory to vue and move it into the webclient folder. The public directory would also be moved into webclient/vue.
vue.config.js
module.exports = {
sourceDir: 'webclient/vue', // Default: /src
publicDir: 'webclient/vue' // Default: /public
}
Or maybe to keep the future in mind, sourceDir
should be contained in projectPaths
or vuePaths
vue.config.js
module.exports = {
vuePaths: {
sourceDir: 'webclient/vue', // Default: /src
publicDir: 'webclient/vue' // Default: /public
}
}
This is NOT something that would make cli-service / webpack move the files automatically.
The vue-cli would then change the vue src path where used by the cli-service.
The 3 places I've seen so far are:
- resolve: { alias: { '@': pathToVueSrc } }
- pages / entry / template
- The public directory would also be located in the pathToVueSrc or another vue.config.js option.
Thanks!
Keep up the good work!
Activity
vue-bot commentedon Dec 1, 2018
Hello, your issue has been closed because it does not conform to our issue requirements. In order to ensure every issue provides the necessary information for us to investigate, we require the use of the Issue Helper when creating new issues. Thank you!
cthames commentedon Dec 1, 2018
@sodatea In regards to your comment. That is why there are defaults and the options only need to be mentioned in the docs. The applicability is for existing and complex apps. As well as, existing projects migrating from another front end framework to VueJS.
As @sam3d mentioned there are no cons that I can think of or mentioned by @sodatea or @LinusBorg and is no different than the
outputDir
andassetsDir
options.I've currently run into this situation with all of the existing apps where I was adding VueJS or upgrading VueJS. If later on you add another feature that requires the
src
path, then everyone will need to change it. It's better to have it in one place.Code wise, having it one variable to make these changes is beneficial to all, including to additional vue-cli changes.
@yyx990803 In regards to your comment, I believe greater adoption will happen with VueJS if it wasn't so constrained and hard coded in the
src
directory (and alsopublic
directory).I disagree with your first point.
Most businesses are not going to start new and re-program all their logic. Nor do only a SPA. Existing projects may already have the
src
and it's being used by another programming language. Also, the majority of projects are going to have a mix of server-side and VueJS code. This is because they probably already have SSR in another language already built and not with VueJS. This would also allow the business/project to be in a transition state. If they had it this way it may allow them to slowly transition to be only Vue JS.I would like to point out to point 3.
The defaults will exist no issues with keeping it consistent with new projects. No con here.
Point 3 also seems to indicate a complete disregard and understanding to existing projects. No business is going to rebuild an existing project to fit Vue JS's structure. If you allow it to easily be customized it will lead to greater adoption as well as greater chances of keeping Vue JS up to date with the newest version. A fragmented ecosystem is not in the best interest for Vue JS.
I lastly respectfully disagree with your point 4.
This option(s) easily allow for these changes as well as make it easier for any additional changes to the vue-cli that may require this path. It is set in one place and not hard coded to
src
. Seems like a no brainer to me, but then I haven't looked at the Vue CLI source code.BTW @yyx990803 and team keep up the good work with Vue!
brhx commentedon Dec 1, 2018
Thank you for taking the time to write that out @cthames, very well articulated! To expand on all of these points, the Vue.js homepage advertises the framework as these two things (among other things):
Point 2 being particularly key here, as this choice seems to go against the nature of incremental adoption that Vue.js strives for (requiring a re-architecting of project structure).
I fully understand and am taking on board all of the points you guys are making (and appreciate you all taking the time to explain your views and standpoints), but this issue honestly seems worth more discussion than you guys have been affording it so far.
brhx commentedon Dec 1, 2018
Also @cthames my thoughts on the proposed API is to use:
Instead of your proposed
vueSrcDir
or various alternatives for the following reasons:outputDir
andassetsDir
,vue
, which is implicit from the purpose of the file,src
as part of the property, andSrc
Thank you again for taking the time to write up such a thorough proposal 😄
LinusBorg commentedon Dec 1, 2018
Just a quick note, I reopened this after it was auto-closed because the effort deserves a repl.
I won't have time for that and seeing as Evan already closed the other issue (#3040), I don't think he has much more to say for the moment.
I'll answer tomorrow after getting some sleep.
cthames commentedon Dec 1, 2018
@sam3d well if @yyx990803 approves I wouldn't mind anyway it's named. However, maybe to keep the future in mind maybe it should be
paths.sourceDir
orprojectPaths.sourceDir
orvuePaths.sourceDir
, see below.Anyway if it happens I'm happy and maybe so will @gmclp @chanlito, @chrishrtmn, @pdmshrestha, @djsmedes, @Nick-Anderssohn, @azjezz, @dumptyd, @vhanla, @Hippocrate and the 13+ others.
brhx commentedon Dec 1, 2018
At least from my end there's honestly no hurry at all.
I understand that as maintainers of a very popular open source project, you guys have to make potentially hard and outwardly controversial choices for feature scope; I just want there to be more dialogue on this issue than the "respond and lock" as all present feedback points towards this being a desired feature.
LinusBorg commentedon Dec 1, 2018
Just another quick quite general reply so I can sleep without wheels spinning in my head: While you're at it, add the /tests folder to the list, or more precise, one unit test folder, one e2e test folder.
Plus, each of these options would also need a CLI options flag for
vue create
, as it would otherwise write into these directories that you don't want to, and break stuff.Maybe you start to see how it's more complex than you think. that's basically why we see it as more useful to integrate the vue-cli project as a subdirectory itself into existing projects.
The existing (usually backend) application won't care where your frontend source and test files are - it usually only cares about where the bundled files end up, which you control with the already existing options (and which is why these options exist)
cthames commentedon Dec 2, 2018
Quick response (well was a quick response, now a little long) @LinusBorg so I don't forget.
In regards to:
I realize your comment was quick, so unless I'm missing something...
I think the incremental step and to avoid confusion for vue-cli is to:
vue.config.js
and thenSo in other words, these options would initially not be apart of the
vue create
process.At least for what I'm requesting with this issue. A new Github issue can be created to integrate it into the
vue create
process and UI (if needed or allowed... I haven't used the UI yet).The reason for this is:
I'm speaking from our point of view, but new Vue JS projects typically start off on their own then are integrated into an existing project after a very basic MVP (minimum viable product). This is to get feedback / buy-in into the new front-end project before it becomes apart of the existing project.
How I see the proposed process for existing projects is:
vue create
a new blank project with Vue JS recommended project structuresrc
.src
towebclient/vue
andpublic
towebclient/vue/public
vue.config.js
optionsvuePaths.sourceDir
andvuePaths.publicDir
to use new project structure.package.json
, etc.)package.json
etc.This allows us to get a very basic stubbed MVP up going quickly without affecting the existing app and get feedback / buy-in. And then when it reaches a point we can then integrate it and start to transition the old front end piece-by-piece to the new Vue JS front end.
If that proposed process doesn't work please let me know and why it wouldn't work.
LinusBorg commentedon Dec 2, 2018
My counter-proposal for the process:
/webclient/vue
directoryvue create .
in this directory/webclient/vue
anymore) - if that even exists.webclient/vue
specificpackage.json
Seems much simpler and much cleaner.
I admit that
/public
may still need some adjustment, as assets might come from a shared project dir, though (but already possible with a CopyWepackPlugin).cthames commentedon Dec 2, 2018
@LinusBorg if I'm understanding then you would have 2 separate
package.json
,node_modules
, webpack, postcss, etc./package.json
/webclient/vue/package.json
If I'm misunderstanding, please let me know.
That would be a developer and project maintenance headache.
We've stayed away from nested npm projects:
node_modules
with hundreds of MB of files duplicated.It is much more simple to have everything in one
package.json
.I believe there is a misunderstanding dealing with existing projects. It's possible that the existing projects we've integrated Vue JS is completely different. However, I suspect that there might be limited experience of having to integrate Vue JS into existing projects (medium / large / complex projects) where the transition to Vue JS is slow and with limited time available to do the transition to Vue JS. There are more important business processes that will have priority over re-writing the client side to Vue JS.
It sounds like (and I could be wrong / misinterpreting) it is expected for Vue JS to be completely separate and in its own site/process. Unfortunately only large businesses with money to spare would spend the resources (people / time / money / etc) needed to rewrite an app that way. The majority of businesses are not large businesses.
Most businesses have limited resources and are not going to transition fully or in a "all in" situation. There are other priorities in a business. Most businesses are not AirBnB / FB / Twilio / etc.
What I'm not understanding, is why this
web.config.js
options request is so difficult? Granted I haven't browsed the code.@LinusBorg @yyx990803 How difficult would it be to:
/src
and/public
private variables to thevue.config.js
?vue create
process would NOT use or do anything with these options. (this can be a separate discussion and separate GitHub issue)If the
/src
and/public
paths are already private variables than exposing them should be rather easy. If they're hard coded then that's another problem, that should be refactored anyways.I believe that in enabling existing projects to easily integrate Vue JS will lead to higher adoption in existing projects and keeping Vue JS updated to the recent versions, without falling behind.
These
vue.config.js
options would then make sure any future changes to the path or any additional Vue features that use these paths are incorporated. This will make updating Vue JS in these existing projects so much easier.It also may turn out that other external Vue JS projects like Nuxt could use them as well, rather than hard coding these values. Keeping the Vue JS ecosystem intact.
Thanks again @LinusBorg for keeping the discussion going. It's nice to learn both sides.
9 remaining items