I am wondering how I should structure the front-end of my Express.js project.
I haven't done much with Grunt before, but I understand that it performs tasks such as compiling, and then saves the result.
Currently, my Express.js project looks like this:
/app
/models
/controllers
/views
/config
/public
Any files inside of /public are static and served as such by the Node app. So, do I initialise Yeoman/Brunt inside of here, or should I store my source outside of the document root, and instead just have it compile to /public? If so, where would you recommend the source?
If you will init brunch project, it’s recommended to do it outside public dir and make it compile stuff to public dir. You can integrate brunch with express: start your express server with brunch watch --server quite simply: https://github.com/brunch/brunch/issues/453
The Yeoman team have setup an express dedicated project which answers this question in the form of back-end generators.
Related
I have a Vue CLI application that I'm currently working on that uses code splitting for JS and CSS, and builds almost 1,000 JS/CSS files on running npm run build.
I am hosting this application on Google Cloud Run, where I pay per request. While the cost is still not that significant, I was still looking to try and prevent the need for 500 requests for every page view. I had a thought, but I'm not sure it's possible...
What I was wondering was if I could have my webpack build generate the JS and CSS files into the dist folder, but reference those files in the index.html file with an external host, instead of assuming a relative path. For instance, the file would exist at dist/css/chunk-abc123.js but in index.html, it would be something like https://storage.google.../css/chunk-abc123.js.
That way, in my CI pipeline, I can upload those files from the dist directory into Google Cloud Storage, and serve them up statically from there.
Does anyone know if this is possible? If so, can you guide me in the right direction?
publicPath comes in rescue.
The base URL your application bundle will be deployed at (known as
baseUrl before Vue CLI 3.3). This is the equivalent of webpack's
output.publicPath, but Vue CLI also needs this value for other
purposes, so you should always use publicPath instead of modifying
webpack output.publicPath.
// vue.config.js
module.exports = {
...
publicPath: 'https://storage.google...'
...
}
I´m starting with Vuepress (https://vuepress.vuejs.org), and i´d followed the docs to integrate it with an existing project (https://vuepress.vuejs.org/guide/getting-started.html#inside-an-existing-project). I used the sugested docs directory.
But now i need to "really" integrate with my project and i need to when my users access the my-project.com/docs, to reach the Vuepress docs
If i make (yarn docs:build), the /dist folder will be generated to be used anywhere as a statics HTML files. I tought in put the /dist/ content in the /static/ files of my project. But the vue-router response to /docs is a 404.
And i will still need to make 2 builds, my project and the docs.
The questions are:
How can i make the vue-router "see" the vuepress build files? Where to put them?
How can i integrate the run build of project to make them both?
I have 2 projects, one with quasar and the other i´m using vue-cli 3.
Thank you all.
How can i make the vue-router "see" the vuepress build files? Where to put them?
You don't, it's basically an external link. A simple <a href="/docs"> should be sufficient.
How can i integrate the run build of project to make them both?
You don't, you add a new task that does them both.
// package.json
{
"scripts": {
"build-project": "node build-project.js"
}
}
from a terminal
# yarn run build-project
I think maybe the point problem is to solve the Vue-Router to make the vue-router don't handle the link when we external link the /docs as like.
I have a project started with the vue-cli, and i'd love to include a component from a different local folder. I'm not that great at webpack config, so I'm not sure if it's just as simple as adding another path to some config setting. I've looked around in the docs, but everything I'm finding shows me the awesome auto scaffolding that vue init project gives us.
Any ideas?
Here's what the project structure looks like:
webroot/
-wp-content/
-wp-admin/
-wp-includes/
-other PHP classes/
-static/
-vue/
-global-components/ (<- this is where i'd like to put some generic .vue components)
-app1/ (<- this was created by vue-cli and is where i'd like to build a specific vue app for a specific wordpress page/post)
-app2/ (<- this was created by vue-cli and is where i'd like to build a different app for a specific wordpress page/post)
So, you can see there's a bunch of things going on in this repo, and I'd like to be able to reference both the src folder inside app1 and app2, but also have each app reference the global-components folder. I'm not sure that the client would like to push their custom components up to npm, and I don't think they want to build out their own private npm source, so I was hoping for a way to build multiple vue.js applications without copying these components to each individual app.
Any thoughts?
I'm developing with ASP.NET Core, and am using jspm, with Visual Studio 2017 RC and WebStorm.
It seems that jspm init expects your absolute lowest level, root folder with EVERYTHING is always going to be wwwroot, and thus the path it establishes (and even more rigidly enforces in jspm 0.17.x beta) iswwwroot/jspm_packages`
However, a new ASP.NET Core project sets up with the node_modules directory, and by proxy the packages.json file, just outside of wwwroot.
Obviously, I can move the file - but it puzzles me that they're different. Some people say "just use a gulp task" but that isn't really an option. I tried that route and it was a complete nightmare to maintain. Plus, jspm seems to load things directly from its package store by default.
So which is it? Is there an inherit problem with the jspm_packages folder being a sibling to the wwwroot folder? Using the UseStaticFiles option in the configuration allows me to specify access to folders outside of wwwroot.
wwwroot is your public folder, this way, all your assets must be inside of it.
You can configure npm to install modules inside wwwroot folder. Take a look in this config page from npm documentation.
However, I recommend you to put your files outside the wwwroot folder, and then, send to wwwroot only the files you're gonna use.
Grunt and Gulp are very simple and useful. If you want to give it a try, take a look in this tutorial. There you can find an example of how to use Grunt with VisualStudio
I am trying to use Aurelia with Symfony backend. Part of our application is generated on the backend (good, old server-side MVC) and part of it should be an SPA. I have started aurelia app from skeleton-typescript (JSPM). Directory structure I am trying to create is as follows.
project/
src/
SomeModule/
SomeOtherModule/
FrontendModule/
build/
src/
app.ts
main.ts
...
index.html
package.json
...
web/
dist/
I have changed the output path in build/paths.js and gulp build correctly places the compiled files in the web/dist. I have also added a gulp task that copies the index.html into the web/.
The biggest problem I have is how to manage the JSPM dependencies. If I configure it to downlad the dependencies into web/jspm_dependencies, the application works when launched with Symfony but I am not able to configure karma unit tests properly (it says for example that it can't find aurelia-polyfills). If I leave the jspm_dependencies in the src/FrontendModule then I have to create a gulp task that copies it to the web/ and it takes a lot more than 10s => unacceptable.
This leds me to the following questions:
What is the suggested directory structure for Aurelia project when I am not going to serve the app from the project's root?
Is there any way to copy only the files needed by the application to the web/ (something like main-bower-files for bower)?
I know I can gulp export the app into the web/, but I want to use the same directory structure during the development, too.
I don't want to use browsersync server in the dev because of multi-nature of the application (SPA part and non-SPA part that has to be served from "real" backend).