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).
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...'
...
}
We're currently using vue as a script file without a build step. We want to start using webpack and vue-cli. We need to preserve the asp login pages and session handling (cookies) so we need the vue stuff and the asp stuff to share an origin.
The current plan is to ignore the vue dev server, to put src and dist inside the existing .net project folder, and to have iis serve the contents of dist. Is this the way to go? We will lose hot reloading.
If we do this, how and where do I configure the url fragment from the web root to the dist folder? Currently, vue expects dist to be the root of the domain.
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
When I download a package in bower or npm, many irrelevant/not-useful files also
get included especially in npm packages. I generally only include .css or .js files of that package for e.g. in bootstrap e.t.c. But for package like polymer or Anjular.js or Electron we need multiple other file too. So when I deploy my project should I include the complete folder or just copy the required files separately or is there any other approach ?
When you deploy to your production server, a good approach would be to only include the files you are actually using. You should also create an optimized file to serve to the client.
To achieve that, you normally have a deploy script that generates one or more minified .css or .js files (for example, vendor.js for libraries and bundle.js for your code).
This script can be build with tools like grunt, gulp or you can use a module bundler like Webpack or Jspm.
You can create your own Grunt or Gulp script like the ones in this website.
When using a module bundler and modern javascript to organize your code, you'll build, for example, an entry javascript file (bundle.js) that will look like
import {MyLibrary} from 'my-library';
import {AnOtherLibrary} from 'an-other-library';
console.log(MyLibrary.saySomething());
In this case, Webpack handles the node_modules imports and the creation / minification / concatenation of the production version of .js files.
As you said, there are multiple files to be included (js, css or even fonts) so configuring your scripts may take some time. Try finding a Yeoman generator that uses your frameworks, and use the deploy scripts others already created for this purpose. This one uses AngularJS, Bower and Grunt. This one uses Webpack and ReactJS.
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.