I have a single page application written in JavaScript ES5 and Angular 1.x, Twitter Bootstrap, UI Router, and several other dependencies. It currently has no modules and no build system and only minimal minification. All code just lives in the global namespace.
The app started out as a prototype and having no build system was fine at first, but now its bigger and not having a proper build system starts to create all kinds of problems.
I would like to transition this app to a webpack 2.x world, as that seems to be the most promising build system right now. But I do not really know where to start.
Ideally I would like to do this gradually, such that I do not have to migrate all files at once.
I have experimented with Webpack 1.x and 2.x for a while, and also created a small prototype that uses Angular 1.x, but I still do not see a way to do the migration step by step. It looks to me as if switching to webpack is an all-or-nothing decision.
Related
Background:
We are developing an electron application which gets bigger and bigger over time. We've separated our web-app (renderer process) and the native wrapper process (main process) into separate projects, which is a good start, but not enough-
We have different teams working on the same electron infrastructure and would like to split the code into separate repos, each managed by a different team, and all of them are being loaded into the main infrastructure project of electron.
Problem:
At first, it sounds simple - create an npm package for each electron module (one for each team) and import those packages in the main electron project, that manages all of them and builds the final electron app. The problem is that those electron packages should be familiar with 'electron' package, and should somehow use the same version of this package. Since keeping track of the package the main electron project uses and updating it manually in every module each time we want to increase it's version is bad for scaled up application, we want to be able to sync them in a better way.
(Bad) solutions I could think of:
Pass the electron instance from the main electron app to the inner packages (in an init function) and use it instead of using the installed 'electron' package. It solves the problem of syncing electron versions, but when the main app updates the electron version - the packages won't be familiar with it and might break in case of incompatibility.
It sounds like no matter what I do, I can't decouple the projects and they must communicate (manually) to work properly. Is there any architecture design method I'm missing that could help me split one electron projects into multiple ones?
We are created #our-company/our-product-common package with common dependencies and configs (electron, typescript, lint rules, global constants). If we want to update electron or typescript we update versions in *-common package.
Or you can create #our-company/our-product-electron package which just reexports electron.
We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.
I'm trying to create angular ui-component, and use it in other angular applications.
I met many problem with angular-cli and decided to get rid it from my project, since it is not ready for building library.
I tried to use webpack, but had a problem with building d.ts bundle(I used dts-bundle, but it can't build bundle with all imports well).
When I created d.ts bundle manually, I realized that project which use webpack don't work correctly with bundly already built by webpack (a lot of errors with third party, module resolution, polyfills).
When I build project with typescript, it worked well, by angular templated (app.component.html), which I don't want to include in my package.
The best way, I think, manage to use something like angular-template-loader
with typescribt compiler, but I don't know how.
May be there is better approach for it, but I read a lot of topics and have't figured it yet.
Thank you.
I am looking to work on an Angular2 datepicker component as if for release and inclusion in multiple projects. What is the best way to structure the project for this compared to a regular Angular2 project built with angular-cli? Are there any examples of good starter projects/seeds for such a task? Or should the component library actually be an angular2 application itself?
My initial assumption was that I could just create a standard project with angular-cli which has a single module (e.g. MyDatepickerModule) which contains a hierarchy of components forming the datepicker however I don't know if this is the best way as I don't need everything that a full application provides.
Thanks for any guidance!
I would publish the library with AoT compatibility in mind.
This means compiling the source using the ngc compiler. In the distribution package I would publish the JS source, original html/css files, d.ts typings files and the ngc generated metadata.json files.
I recommend publishing the JS source with es2015 modules since this will make your library tree shakable. I would target es5 JS, but with es2015 modules . TypeScript allows for this hybrid mode by setting module to ES2015 and target to es5 in tsconfig.json.
Publishing these files will make your library AoT compatible and Tree shakable.
This is all the consuming application needs in order to AoT compile your library into their complete application.
It's not recommended to publish TypeScript in your package since this would require the consumer to replicate your build environment (typings + TS compiler version).
You can also publish a JiT compatible umd bundle with inlined templates and css. This can be helpful since it might not be practical do AoT during development since compilation is a bit slow. The umd bundle will make it possible to use your library in a JiT based dev environment. For production though you should definitely use the AoT version.
The CLI is not ideal for publishing libraries since CLI is primarily a tool for building complete applications. They might support libraries better in the future though.
Check out https://github.com/angular/material2. A work in progress, it's a library of controls and themes for Angular2 applying Material Design and is an excellent source for learning to build your own control library.
I'm an Angular 1 dev currently looking to get to grips with Angular 2, however with the changes and rewrites so far it's a bit of a quagmire.
All of the full ecosystems I've found are from late 2015, the testing ngdocs are outdated and there doesn't seem to be a clear up to date scaffold for Angular 2.
Has anyone come across a recommended setup or been able to set something up themselves? Something like Yeo is not strictly necessary but I'd need Typescript compilation and linting, live reload for development, unit testing, minification, SASS compilation and dependency management.
I would default to Gulp, Jasmine & Karma for the build system and tests but ideally I want to start off learning the best suited technologies from the start.
Bonus points for Webstorm integration :)
I'd check out the Angular-CLI project. It's an official CLI toolchain with testing and build built in. It's still a bit unstable with the changeover to webpack, but if you're working with RC software that's to be expected.
While waiting for angular-cli to become a bit more mature, I've been using the Fountain Webapp generator. Long term, I'll probably move to angular-cli.