I recently found out about Yeoman and found it can be very useful in improving workflow. However, I noticed it seem to focus only on client side projects? ExpressJS is a popular framework that seems to be been missed out?
However, I still think its possible to integrate it into Yeoman, perhaps with custom generators? Is there something like that already available? If not how might I start?
It will not be as simple, along with Express, I will be using Jade/Stylus the defaults express uses for precompiling HTML and CSS.
The initial goal of Yeoman was to tackle front-end web apps.
Opinionated workflow with the back-end is planned, but is currently a bit cumbersome to do. Use of Jade/Styles is possible, but a bit ugly.
All this will be much easier with Yeoman 1.0, which will be more customizable and will let you use whatever grunt tasks you want.
Related
I want to develop projects with js or ts. I learned expressjs and found it's very flexible like ruby on rail. Then I found this nestjs is like RDF. Make the developer write code in the same/fixed way. I think it's good. How do you guys think about it?
I am being thrown a half backed, undocumented, non-handover project of VueJs with few other components as frontend and express as a backend. (Old developer who was maintaining things on git is abscond)
Backend/Express part I've figured it out most of the things but I got stuck on frontend part which is served using express_static
For VueJs I don't know what other things are depending
Is it using yarn or npm for build/deploy ?
Using mostly command line
What should be my starting point to look into project
Build/deploy yarn <> npm is interchangeable.
Is it possible to convert Individual .vue file to .js file and deploy it?
What other tips and tricks you suggest for making quicker changes live on productions without major disaster (on front-end side).
What is the fastest way to hack things in this situation :)
Is there any docs what happen internally? - Curious to know!
Thanks
Is there a tutorial somewhere that shows you how to install & build Aurelia MANUALLY in Visual Studio 2017?
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
I'll learn every aspect of the build/bundle/package process as possible instead of having a tool set that up for me. (Makes things
easier to troubleshoot if I know how it is all setup.)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
I've tried several CLIs and "skeleton" projects but they all have their issues. Some haven't been updated to use the latest csproj.
Aurelia CLI: Project/Folder structure doesn't mirror any standard way of building SPAs that I've seen. Also doesn't mirror what you get when using Aurelia's own "Skeleton Project."
dotnew new spa templates: Though the most promising it's typescript only and not ES6. (Maybe there is a way to switch it easily?)
Aurelia's Skeleton Projects It adds dependencies that I do not need. It also does not work out of the box.
So here is what I've determined since originally writing this question.
My original thoughts with lessons learned:
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
Answer: I was only doing this because I was trying to embed Aurelia inside of a web api project in Visual Studio. I recommend you don't do this and instead keep it as a separate project. (Separation of concerns)
I'll learn every aspect of the build/bundle/package process as possible
instead of having a tool set that up for me. (Makes things easier to
troubleshoot if I know how it is all setup.)
Answer: Though building from scratch would help me learn about this more it isn't a major roadblock. I was just inexperienced with more modern UI frameworks and their corresponding build processes. (RTFM)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
Answer: - That happens no matter what route you go. You can wait for a library to mature more if this is a big concern.
The bottom line is my question was based on some incorrect thinking. If you are trying to go this route you really need to ask yourself why and determine if it is worth it. To me it was not. Just go with what works, learn and move on. Oh and don't resist Typescript!
npm install aurelia-cli#0.30.1 --global
create new vs solution in 2017 (ASP.NET Core Web App)
with command prompt, cd into the solution root dir (not wwwroot)
au new --here
select RequireJS or SystemJS (my personal preference)
select option 2, asp.net core
select the remaining options.
Run f5 in VS2017.
I've been developing in Aurelia-CLI for about 3 months and like it so far. I think it's a solid framework and obviously escalating in support and usage. That's a good thing!
Before I develop much more of my large app, I'm wondering if I'm using the best build system. I've only tried Aurelia-CLI and am not really familiar with Webpack or JSPM, and therefore I don't know what I'm missing. Are there any clear advantages or disadvantages in using either of the other two build systems, or is using the CLI the most clean and supported approach? Since I'm developing independently, I don't have any external constraints.
Thanks for your help.
UPDATE
This answer is almost two years old. Feel free to research updates and provide another more complete answer and I can replace this answer or point to that answer. Thanks!
Aurelia CLI
Aurelia CLI is great for getting started. It's important to understand that under the covers the CLI is using require.js but proxies the configuration through aurelia.json in your application. This means that you need to understand how to configure aurelia to work with require.js at the moment. Once you need to start configuring to match your workflow or change build steps up it gets a bit cumbersome at the moment. We are working to improve this. There are many features planned for the Aurelia CLI but given at the time of writing this that it is in an alpha / beta state it should generally be used on proof of concept or other smaller apps, not production-ready large scale apps yet.
WebPack
WebPack is arguably the most popular kid on the block at the moment. WebPack is not a module loader, but a bundler. It's important to understand this because while we strive to make Aurelia work great with all module loaders WebPack by default is not in charge of loading modules so a dynamically loaded application requires the developer to expand on this. WebPack is strong in creating optimized bundles and can be easy to use as long as you are comfortable with configure WebPack. WebPack has considerably more GitHub stars due to the popularity from React using WebPack it's hard to say whether the choice is better when using Aurelia simply because of the number of GitHub stars.
JSPM / System.js
Some of the skeletons use JSPM and System.js. The reason is that these are the closest to 'spec compliant' solutions. JSPM tries to help as much as possible when loading from the JSPM registry. If not yet available in the registry you can load from NPM or GitHub directly. From a module loading perspective you use a config.js file that is (usually) automatically maintained when installing dependencies to improve the developer workflow.
Side biased note
On most larger apps at the moment I typically prefer using JSPM / System.js simply because I have a great understanding of the tooling and prefer the control that I am provided. I work on a great number of Aurelia apps that are in production and typically reserve CLI for smaller proof of concept apps and WebPack is a great alternative but I prefer the flexibility and understanding I have with JSPM / System.js at the moment.
The CLI isn't currently feature complete, but it is a much simpler setup. Webpack can basically do anything you want to do, but you'll be maintaining your webpack configuration just as much as you maintain your Aurelia code.
Ok, maybe not just as much, but you'll have to learn Webpack to use webpack. The Aurelia CLI is simple to get started, but has some definite limitations. For example, CSS files that reference external resources won't work w/the Aurelia CLI, but they should work fine with Webpack.
First, I can understand if this post gets shutdown due to its subjective nature.
I believe it's time to re-visit the answers about Aurelia CLI being a second-class tool. I respect both PW Kad and Ashley Grant immensely, but I am just not convinced that a statement like this is true anymore:
There are many features planned for the Aurelia CLI but given at the
time of writing this that it is in an alpha / beta state it should
generally be used on proof of concept or other smaller apps, not
production-ready large scale apps yet.
Notably, I have a production application that way back in the day I started with Aurelia CLI, and changed it to JSPM precisely for the reasons noted. But recently, I rebuilt the same app from scratch using the CLI and I realize that it is much easier to use, particularly managing modules and publishing! And this is an app with Google Maps, Google Analytics, Auth0, DevExpress, Bootstrap, etc.
Just think it is time to give Aurelia CLI a little love. It's ready.
Aurelia CLI is the most preferred option with this announcement.
http://aurelia.io/blog/2017/08/18/aurelia-cli-webpack-update/
Now It has more flexibility for your choice of preferences.
I really like the idea of this BundleTransformer plugin from NuGet, and I see that they have LESS support. But ...
After weeks of trying, I cannot find any decent example of how to use it. The documentation is unclear, to say the very least. This is the closest I could find, which does not compile or work.
who-could-ask-for-more-with-less-css
Well, the simple answer is that I could ask for more.
Can someone please assist me with the simple task of creating a bundle that has .less files in it, that will run? I am completely lost.
I would suggest reading the wiki page for bundle transformer and also, as the wiki page suggests, make sure you are familiar with ASP.NET bundling and minification.
If you follow the examples of usage you should be up and running.
I know this is an older post but figured I'd chime in. The Bundle Transformer Codeplex discussion board (Feb 2015) mentions that BundleTransformer is no longer considered a modern client-side build tool and they are recommending you go with Gulp or Grunt - which both have support starting in Visual Studio 2013.3 via VSIX extensions and more baked in to VS2014. FYI -This Scott Hanselman post explains how to get up and going with Grunt and Gulp in Visual Studio. I think if you're using BundleTransformer for simple Less compilation it works fine, but doesn't allow you to do things like generate CSS Sourcemaps which make your browser's dev tools aware of the Less source files, which in my humble opinion is critical for using a CSS preprocessor - the ability to see the LESS line numbers of your source files in the styles pane.