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.
Related
I want to create a Vue app, so I started by using the Vue CLI to do so, but the app.js bundle is 1.2 MB before I've even really done anything. I'd like to bring that way down, as I really don't want/need all the stuff that is being bundled into that file.
Specifically, I would like to have a Vue app with Babel so I can transpile ES6, Webpack for bundling everything, and Sass for the CSS.
What's the easiest way to create a Vue project like this without all the bloat that occurs when I use the Vue CLI? And what I'm specifically looking for is instructions on how to install (I'm assuming just use npm) all of these things and then setting them up to work together, which is the part I'm stuck on.
I can set up Webpack by itself, and I can set up Vue by itself, but I don't know how to get Webpack to compile Vue files, and I don't know how to set up Babel to work with all of this and transpile everything. Thank you.
I want to write a node cli application and im wondering how i should structure the application. Im fairly new to node and im a confused with all the design patterns used when building such a application.
I want to be able to call the application from the command line, but also use it as a node module for better testing.
Currently i have one file with lots of functions that get called directly from the cli, but i feel this is rather difficult to maintain.
Is there any good writing on how to do such things? i looked at rimraf but it confused me even more. Thanks for your time
I don't know if there is a "right" way to do it but I can tell you how I have dealt with a problem similar to yours. I wanted to create a CLI and a visual studio code plugin so people would be able to use the functionality both from VSC and from the CLI (for those that don't use VSC), so the approach I took was to put all the logic in its own package and then create two other packages that included the first one, one for CLI and one VSC plugin that required the "logic" package.
In the CLI package you would only have code strictly related to command handling and then the real meat happens in the logic package. In my case the VSC plugin package had very few lines of code, just configuration and the calls to the needed functions.
Then regarding the structure of the code some recommendations:
expose only what is strictly necessary
isolate your code in different files/classes based on common functionality (and go to point 1)
test your code
lint your code
But those are common sense and language independent recommendations.
There's no one "standard" way to structure Node.js apps, however you will notice that many authors follow similar patterns. Instead of having one file containing all code, it should be split out into modules, grouped by function. Have a look at this repo on Github, it has some very good suggestions about Node.js best practice https://github.com/i0natan/nodebestpractices#1-project-structure-practices.
A couple more pointers I would add: Ensure you're logging any errors, consider using something like Winston.js for this purpose. Also have some mechanism in place to restart the service if a critical error occurs, e.g. Forever.js.
Ensure likewise you're unit testing, there are some good test frameworks, Jasmine, Mocha, Cucumber.js.
I have a question about using angular-cli. I had used it, but I had trouble with override webpack conf, sass files, assets conf. In other hand I have nice boilerplate with karma tests sass and other confs, which is enough for most projects. Which solution is better? angular-cli or spent some time and get own custom boilerplate?
It is a personal answer and every developer would have its own.
Mine is:
Angular-cli should be up to date with the latest things in Angular 2 while with your own build/compile process may not.
There is no problem in using your own set, but you can be out of date without even known and end missing some good features that angular-cli may have.
But you should use what you think is better for you and your project. Any option will work. Like I said, is more a personal opinion then a absolute truth.
I have written a self contained angular js module using browserify in order to make use of the commonJS/Node style syntax.
The module works fantastic when tested by itself, so I then use gulp to minify and host that on GitHub.
I've then imported that into another app that is also using browserify. When I run browserify it seems to try and rebrowserify the module and causes no end of problems.
I believe this is because the module requires angular and jquery and qtip2. So it's obviously trying to re parse these.
Is there a standard to not parse modules, or is there a way to exclude the browserifying of the modules? Or is it best to not include things like angular and jquery within your modules? I was trying to make them perfectly stand alone, maybe that's unwise?
Many thanks!
I would suggest providing both options, if it is important for you to have a standalone version that includes angular. This will provide people using your code with a total of three ways of using your code: Using the standalone version, the version that only includes the module, and cloning the repository directly and including the source files as part their build process.
I generally use the third option, but people who don't have build processes will likely prefer the first or second.
I'm trying to embed an EmberJS application into a large portal application which uses extensively the RequireJS library. I'm using ember-cli to build the project. The built application consists of two files, dist/assets/vendor.js and dist/assets/myapp.js. The EmberJS application works after embedding it but the portal app's javascript breaks.
After some research I've found out the problem is that vendor.js defines its own variables require, requirejs, requireModule and define which conflict with the website's variables in the global namespace. The myapp.js file then contains define statements which load the app's modules.
Is there a way to rename these or to put them into some different namespace?
The only solution I came up with was to manually rename the variables within the two .js files. This seems to work but it's rather cumbersome and it'd be nice if it could be automated. I have also found out about using RequireJS optimizer but I can't get it to work with the vendor.js file.
Can you help me?
Thanks!
I was having the same problem, and after much searching I believe I managed to solve it by adding the ember-derequire addon to my project:
ember install ember-derequire
That will change all of the 'require' and 'define' statements in your app to 'eriuqer' and 'enifed'. You can override what it maps to using options (caveat being you have to use something the same length) if you don't like eriuqer and enifed.
In case that doesn't help, the other promising thing I found is that loader.js has a noConflict() function, but I couldn't figure out where to put the loader.noConflict() call, or get the build to generate code using alternate names, but maybe it will help you if the first option doesn't work for your situation.
As #Bjornicus (https://stackoverflow.com/a/39088322/5056421) wrote, built-in loader.js's noConflict() function seems to work correctly. I placed it in main JS file (app.js):
window.loader.noConflict({
define: "emberDefine"
});
and define wasn't overridden (I import ember app to another app which uses SystemJS). But I've made only few tests, so I don't know if this does not break something later.