What benefits to use componentjs (https://github.com/component/component) instead of requirejs?
Both project has the same idea, hard to make choice between them.
RequireJS is just a JavaScript file and module loader.
Component is a whole system which allows you to package HTML+JS+CSS+Images+Fonts in a one module, component. Component also provides package registry(vs npm), dependency handling(vs requirejs), build and task system(vs grunt/gulp).
There's good document where component is compared to other build/package handling tools:
https://github.com/component/guide/blob/master/component/vs.md
This blog post helped me to understand component: http://blog.benmcmahen.com/post/55280740882/using-component-js
Related
why not simply use folders instead of modules if the only purpose is to make the structure more organized?
It is weird because it does not seem necessary since every file is a separate module in node js and if i need anything i have to import it using the import statement anyways so what is the point of specifying the imports and exports in a module? does it affect the dependency injection if i just import what i need without using modules(#Module decorator) or something similar?
NestJs has opted to design their framework with dependency injection as one of its core principals. Ie, you write your code just using the name/type of the services you want to use, and then a different piece of code is responsible for finding that service, knowing how to construct it, and then passing it in to you.
Native import/export doesn't have a system for dependency injection, so the main thing that the #Module decorator does is organize the metadata needed for the injector system.
I have a codebase with for example 3 components.
I want to create one file with all svelte files and then export all of them.
so with that, I turned my codebase to become a library, which I can reuse with other codebases.
in javascript I always used export default {func1, func2}
so I can do in another files import func1 from library
and In the docs they suggest to use #svelte.js/package
https://www.npmjs.com/package/#sveltejs/package
which haven't done 0 docs about it, and nothing works.
except for this https://kit.svelte.dev/docs/packaging but don't show the steps to do either.
for more info: I am not using sveltekit, but svelte.js framework.
I writed:
npm i #svelte.js/package
I writed then svelte-package -w
but there is error: command not found
I also when installed the package get this
33 VULNERABILITIES
is this a beta? should not use it?
if yes how to do then this?
another thing I am using vite as bundle if you interested in.
As is stated in the read-me:
This is part of the SvelteKit framework and CLI.
This is meant for packaging output of SvelteKit; if you are not using that, then your output probably will not be compatible/correctly configured.
In an Ember app, when using certain dependencies like moment installed via bower, we have to also import the same in the ember-cli-build.js file:
app.import('bower_components/moment/moment.js');
My question is why is that needed, since I would assume everything inside node_modules as well as bower_components should be available for use inside the app.
Also if that is not the case, how do we identify which dependencies would require such explicit import to be able to use them ?
You don't have to, actually.
There is a package now that lets you 'just import' things: https://github.com/ef4/ember-auto-import
Some reading on the topic of importing: https://discuss.emberjs.com/t/readers-questions-how-far-are-we-from-being-able-to-just-use-any-npm-package-via-the-import-statement/14462?u=nullvoxpopuli
In in-depth answer to your question and the reasons behind why things are the way they are is posted here:
https://discuss.emberjs.com/t/readers-questions-why-does-ember-use-broccoli-and-how-is-it-different-from-webpack-rollup-parcel/15384?u=nullvoxpopuli
(A bit too long for stack overflow, also on mobile, and I wouldn't want to lose all the links and references in a copy-paste)
Hope this helps
Edit:
To answer:
I just wanted to understand "in what cases" do we need to use the import statement in our ember-cli-build (meaning we do not do import for all the dependencies we have in our package/bower.json)...But only for specific ones...I wanted to know what is the criteria or use case for doing import.
Generally, for every package, hence the appeal of the auto-import and / or packagers (where webpack may be used instead of rollup in the future).
Though, it's common for ember-addons to define their own app.import so that you don't need to configure it, like any of these shims, specifically, here is how the c3 charting library is shimmed: https://github.com/mike-north/ember-c3-shim/blob/master/index.js#L7
Importing everything 'manually' like this is a bit of a nuisance, but it is, in part, due to the fact that js packages do not have a consistent distribution format. There is umd, amd, cjs, es6, etc.
with the rollup and broccoli combo, we need to manually specify which format a file is. There are some big advantages to the rollup + broccoli approach, which can be demonstrated here
and here
Sometimes, depending on the transform, you'll need a "vendor-shim".
These are handy when a module has decided it wants to be available on the window / global object instead of available as a module export.
Link: https://simplabs.com/blog/2017/02/13/npm-libs-in-ember-cli.html
(self represents window/global)
however, webpack has already done the work of figuring out how to detect what format a js file is in, and abstracts all of that away from you. webpack is what ember-auto-import uses, and is what allows you to simply
import { stuff} from 'package-name';. The downside to webpack is that you can't pipeline your transforms (which most people may not need, but it can be handy if you're doing Typescript -> Babel -> es5).
Actually: (almost) everything!
Ember does, by default, not add anything to your app except ember addons. There are however some addons that dynamically add stuff to your app like ember-browserify or ember-auto-import.
Also just because you do app.import this does not mean you can use the code with import ... from 'my-package'. The one thing app.import does is it adds the specified file to your vendor.js file. Noting else.
How you use this dependency depends completely on the provided JS file! Ember uses loader.js, an AMD module loader. So if the JS file you app.imported uses AMD (or UMD) this will work and you can import Foo from 'my-package'. (Because this is actually transpiled to AMD imports)
If the provided JS file provides a global you can just use the global.
However there is also the concept of vendor-shims.. Thats basically just a tiny AMD module you can write to export the global as AMD module.
However there are a lot of ember addons that add stuff to your app. For example things like ember-cli-moment-shim just exist to automagically add a dependency to your project. However how it's done completely depends on the addon.
So the rule is:
If its an ember addon read the addon docs but usually you shouldn't app.import
In every other case you manually need to use the library either by app.import or manual broccoli transforms.
The only exception is if you use an addon that tries to generically add dependencies to your project like ember-browserify or ember-auto-import
When I work with angular2 code I often need to see the implementation of a class, let's say the Router class.
If I click on the Router type in my IDE WebStorm, e. g. inside the constructor of another class
export class myClass {
constructor(private router: Router) {}
// ...
}
my IDE takes me to the TypeScript definition file router.d.ts inside my node_modules folder. What I want is it to take me to the original router.ts file with the implementation of the router class, not just its definition.
The original .ts file is not included in the node_modules folder structure when you get angular2 from github via the standard package.json suggested in the Angular2 Quickstart. Currently, I have to look up the original code in the official github repo.
Any ideas how to get the .ts files into my node_modules/#angular folder instead of the .d.ts files?
Sadly, it's not possible since no TS files exist. Even if you add them it still not possible since you import real angular paths which always point to the definition files. On top of that the file structure of the project does not correlate to the structure of the import string literals.
Some background and more information
The NPM package does not include .ts files, this is by design from the angular team. Up until some time ago the .ts files were indeed supplied with the NPM package.
The reasoning for removing them is to disable abuse from users accessing private classes and #internal and private APIs which is public methods/properties in the API that are not supposed to be public but must be so other angular internal classes can use them.
We used to see a lot of code samples out there doing things like import { PromiseCompleter } from 'angular2/src/facade/lang'; (before RC0) but this was changed when the project structure had a big structure refactor in RC0. This abuse was wide and it's bad, very bad... For users and for Angular PR.
The Angular project has a complex and robust build process where all of the API is moved from .ts files into d.ts files using an automated process that limits exposure. (public_api_guard)
The end result is d.ts files only.
It's also not possible to clone the git repo and use it since, again, the file structure is way way different so imports will have to change. Most importantly without the build Angular will, most likely, not work.
A solution using a different approach
However, if you debug your app you notice that you reach actual angular core .ts files in the source view of the console, this is because the NPM package comes with source map files that include the whole TS source code. Nice trick they did there.
This is what I use to dig deep into angular, it works quite great and I get a lot from it.
It's not as nice as Goto Declaration but it something...
IMO it's also easier to understand when you step through code...
Went with the runtime-only build version of Vue.js for a new project. I saw in the docs that to switch to the standalone one needs to add an alias to webpack, like so:
resolve: {
alias: {
'vue$': 'vue/dist/vue.js'
}
}
At the moment, I don't need the compiler in my app. However, it's possible that at some point I will need to switch to the standalone build.
My question is:
Will it be a painless switch between runtime-only and standalone later or will it require heavy refactoring?
If it does, I might as well start with standalone and avoid refactoring later on.
standalone supports template option in components. For example, you can do this:
Vue.component('my-component', {
template: '<div>A custom component!</div>'
})
standalone also allows you to load vue.js from a CDN, like you would do with jQuery or any other javascript library.
runtime-only does not allow you to use template in component definition. So you need to create my-component.vue file and define template inside as detailed in Single File Components guide: http://vuejs.org/guide/single-file-components.html
Also you need to use vue-cli for development, if you are using runtime-only.
To switch from standalone to runtime-only, you will have to rewrite all the components into my-component.vue files, and start using vue-cli
To switch from runtime-only to standalone, there are no changes required.
Other than that, it is painless to switch between runtime-only and standalone.
My preference: runtime-only only mode, as it produces much smaller builds and theoretically performs better, as templates are pre-compiled. Also the sections in vue file are well organized and easy to read. Separate vue files for components also forces you to structure your app better.