I'm using BabylonJS in a StencilJS app, and I can only seem to import in a very specific way.
For instance I can't do:
import { Engine, Scene } from "babylonjs";
It says 'Engine' is not exported by node_modules\babylonjs\babylon.js
But it is..
I can do:
import BABYLON from 'babylonjs';
and use it like
private _scene: BABYLON.Scene;
I'd like for the former to work. Any advice?
The first way is how most tutorials do it, and I refuse to believe SencilJS is just not capable of that. I must be missing something
BabylonJS is provided in two versions (ES5 and ES6). The issue you are referring to is related to ES5 version of package.
If you do smth like this in your code
import * as babylon from 'babylonjs';
console.log(babylon);
and look into the console, you will see next:
{default: Module, __moduleExports: Module, babylonjs: undefined}
That's why decomposition is not working, it's not an object that can be serialized the way you expect.
In documentation they say
import { Engine, Scene } from 'babylonjs';
NOTE: if you can't make this import method to work, go to the section on typescript and webpack below.
However, I failed to make it work for ES5 version. The correct way, as to me would be to use ES6 version of package, which can be installed as
npm install -S #babylonjs/core
This version allows you to use ES6 packages together with tree shaking and other useful features.
Your module import, in this case, would look exactly as you wish:
import {Engine, HemisphericLight, Mesh, Scene} from '#babylonjs/core';
Here is a small example I've done to prove my words.
Please, let me know if I got you wrong and you expected to have smth different or you need some additional explanations or materials - I'll be happy to assist.
Related
I've noticed that React can be imported like this:
import * as React from 'react';
...or like this:
import React from 'react';
The first imports everything in the react module (see: Import an entire module's contents)
The second imports only the default module export (see: Importing defaults)
It seems like the two approaches are different and fundamentally incompatible.
Why do they both work?
Please reference the source code and explain the mechanism...I'm interested in understanding how this works.
Update
This is not a duplicate of What is the difference between import * as react from 'react' vs import react from 'react'
That question was answered with general ES6 module information.
I am asking about the mechanism that makes the react module work like this. It seems to be related to "hacky" export mechanism in the source here but it's not clear how that enables both importing the entire module and just the default export into React and having both of those approaches work with transpiling JSX, etc.
TL;DR
Indeed ES import statements import default and import * are not the same thing, the fact that they behave the same in this case is a combination of how React authors chose to publish the library and compatibility layers in TypeScript (using esModuleInterop) or Babel and your bundler to make them "just work". It probably shouldn't work according to ES6 spec, but today we are still working in an era where JS modules are a mess, so tools like Babel, TypeScript, Webpack, etc try to normalize behavior.
More details:
React is not an ES6 library. If you look at the source code you see this in index.js:
const React = require('./src/React');
// TODO: decide on the top-level export form.
// This is hacky but makes it work with both Rollup and Jest.
module.exports = React.default || React;
(Note the comment, even in React source code they struggle with ES6 default export compatibility.)
The module.exports = syntax is CommonJS (NodeJS). A browser would not understand this. This is why we use bundlers like Webpack, Rollup, or Parcel. They understand all kinds of module syntax and produce bundles that should work in the browser.
But even though React is not an ES library, both TypeScript and Babel let you import it as if it is (using import syntax, rather than require(), etc), but there are differences between CJS and ES that have to be resolved. One of them is the fact that export = can give you things that ES has no spec-compliant way to import, like a function or a class as the module. To work around these incompatibilities Babel has for awhile allowed you to import CJS modules as if they were exporting something by default, or import as a namespace. TypeScript for awhile didn't do this, but more recently added that as an option under esModuleInterop. So now both Babel and TypeScript can pretty consistently allow a CJS module to be imported using default or namespace ES imports.
With TypeScript it also depends on how the type-definitions for the library are actually defined. I won't get into that, but you can imagine situations where thanks to transpilers and bundlers a particular import works at runtime, but TypeScript doesn't compile without errors.
Another thing worth mentioning is that if you look at the built code for React there is a UMD module version as well as the CJS version. The UMD version includes some gnarly runtime code to try to make it work in any module environment, including the browser. It's mainly for use if you want to just include React at runtime (ie you don't use a bundler). Example.
Confusing? Yeah, I think so. :)
You most likely have "allowSyntheticDefaultImports": true, set in your tsconfig.json, which essentially shuts the compiler up about default imports it thinks are invalid. Typescript added esModuleInterop which does essentially what babel does for module loading.
This allows you to use ES6 default imports even when the source code you're importing doesn't export anything as default
Typescript is strict (follows the rules) when it comes to this, which is why they require you to import * as React from 'react'. Or requires you to tell it to allow synthetic default imports in its base config.
More On That Here
So my goal is to create a library in Typescript. My intention is to split up core parts of the library into submodules like RxJS or Angular Material.
RxJS and Angular both support imports like so:
// RxJS
import { map, filter } from 'rxjs/operators';
// Angular
import { MatButtonModule } from '#angular/material/button';
However, I am unable to replicate this myself.
My goal is to do something similar and allow you to import a class with import { foo } from 'package/bar;
I have looked at RxJS's source on Github and have tried replicating what they've done but it's not working.
The library compiles fine but when I go about importing it I always get a Cannot resolve dependency 'package/foo' error.
Meanwhile doing import { test } from package (without the submodule part) works completely fine.
I've tried using paths in tsconfig to no avail. If that is the answer then I'm doing it wrong.
How do I go about doing this?
In order to achieve that, you can create your "sub-modules" in different directories (although they are technically part of the same module), and create an index.ts on each of those directories exporting there whatever you want to publish.
For example, I have done this in my NodeJs package Flowed, and you can for example do this:
import { FlowManager } from 'flowed/dist/engine';
Where the corresponding index.ts file is this one if you want to check.
Although in my case I put also available all the stuff from the root, so the previous line would be equivalent to:
import { FlowManager } from 'flowed';
Does an NPM package need to be modified to be compatible with Angular 2 (eg. add in typings, make directives for them) or will any existing package work? If they're not all compatible, how do I know what is and what is not compatible?
For example, say I want to import this package (https://github.com/pvorb/node-md5). I'm aware there is a ts-md5 package for angular 2 to do md5 - I'm just using this package as an example.
How would I get this to work?
I've installed it using
npm install md5 --save
npm install #types/md5 --save
but I can't seem to be import it
import {md5} from 'md5';
I get this error message after I try to run
Module
'"/Users/xxx/Source/tempProjects/ngUnderscore/node_modules/#types/md5/index"'
resolves to a non-module entity and cannot be imported using this
construct.
I'm not sure what this message means. Does it mean that in its current state, the package is not compatible or am I trying to use the package incorrectly?
I managed to make it work using declare and require instead of import (import won't work for this non-module lib)
declare const require: any;
const md5 = require('md5');
If you don't want to workaround import like this, you can try using Typescript MD5 implementation called ts-md5. Then import like the one below should work. (referenced from this question)
import { Md5 } from 'ts-md5/dist/md5'
If there is no TS implementation, you can search for the types in DefinitelyTyped and then simply install package by npm i --save-dev #types/{package-name}
If the library works on your project depends on many factors: your Angular version, your TypeScript version, etc.
This said, is obvious that we should check the library's documentation and see which dependencies has and its versions, and of course the library should be the Angular 2 version of itself. Following your example, there are several md5 libraries but if you use TypeScript you should maybe consider this one: https://www.npmjs.com/package/ts-md5
If we have all that covered but still there is something not working because of some type of incompatibility, like for example:
My version of angular is 2, the library I just installed works with Angular 4. I have code full of <template>, library uses <ng-template>... What can I do?
You can fork the library in github and modify whatever you need to asure it is compatible with your project. Steps:
Fork library repository and modify what you need
Subscribe to main library repository in order to be updated with changes
In packages.json use your forked version of the library, for example:
"ng2-datetime": "https://github.com/my_user/ng2-datetime/tarball/my_forked_version_name",
If you think that your modifications could suit other users... Make a Pull request! :D
This is more of a TypeScript question since md5 is not an Angular package.
The key is to get the import correct to be equivalent to a require() function.
import * as md5 from "md5";
Use directly in TypeScript file:
console.log(md5('message'));
To use this on the template, preferably it should be used in method implementation, but can also be exposed directly. Add it as a property on the Component:
md5: any = md5;
Then on the template:
{{md5('message')}}
They usually say which Angular it is meant for, sometimes you have one package for both or for each.
If you are using an Angular 1x package and there is no Angular2 compatibility, then you can just use ngUpgrade.
But If you are using a common plugin then there must be an angular 2 solution.
If you want the other way around then you're probably going the wrong way.
The issue you experienced is not related to Angular. It is an existing issue on TypeScript when importing CommonJS packages.
The rule of thumb (my recommendation) is to stay away from using the interop feature (i.e. import * as X from 'x') when importing CommonJS and use the "old" syntax instead (i.e. import X = require('x')).
When CommonJS is exporting a function in the form of module.exports = function() {...}, import * as X from 'x' does not work.
This includes the case when the package is exporting an ES6 class but transpiling to ES5 with Babel.
You may see some packages do work with this syntax, but that is because the typings have a hack in it:
declare module 'x' {
function foo(): void
namespace foo {} // <-- the hack
exports = foo
}
There are other reasons the interop is not a good idea, including the syntax between TypeScript (import * X from 'x') and Babel (import X from 'x') does not agree.
You can learn more about it here and follow the links:
https://github.com/unional/typescript-guidelines/blob/master/pages/default/modules.md#import-keyword
UPDATE: with TypeScript#2.7 released, you can now do import EditableElement from 'Transformer' directly.
Turn on esModuleInterop in your tsconfig.json
I happen to need a file storage database and UploadFS seems to be the best option. My project is in Angular2 typescript and Meteor.
meteor add jalik:ufs-gridfs
So far it fails when I try to import the library like this:
import {UploadFS} from 'meteor/jalik:ufs'
The error thrown sais it couldn't find the library (on the client side).
I thought it may be because the library is in javascript while the rest of the project in typescript so I tried to write a stub ufs.d.ts, first handcrafted, then with dstmake, and then by hand again when I found I had to export the module UploadFS so that meteor (barbatus:typescript?) could see it:
declare module 'meteor/jalik:ufs' {
export module UploadFS{
interface UploadFS {
...
}
}
}
So far I had my ufs.d.ts stub file at the typings/ folder and linked in the main.d.ts. No errors at compile time. Meteor sad the DB was correctly created ... but then when I tried to use it broke.
I found that UploadFS was undefined so I supposed it wasn't referencing the library even though Meteor compiled without any error.
So I suppose the only thing I've have left is to translate jalik:ufs and jalik:ufs-gridfs to typescript by hand. Is that correct? Is there an easier way of making ufs work wit angular2-meteor?
Would you use some other storage solution? any advice either fixing this library or choosing another one?
I'm successfully importing that library and just suppressing the warnings with this line:
import 'meteor/jalik:ufs'; declare let UploadFS:any;
Keep an eye on https://github.com/meteor-typings and https://github.com/Urigo/angular2-meteor/issues/102 for proper type definitions in the future.
You should never have to re-implement a JavaScript library in TypeScript in order to use it.
import { UploadFS } from 'meteor/jalik:ufs';
console.log('UploadFS', UploadFS);
This gives me the UploadFS object and I think it's totally independent of angular2-meteor so I suppose that jalik:ufs should be working fine, even with those warnings generated by ts compiler.
About typings, those warning are very annoying, I know :) but you can pretend for now you don't see them.
Here's an example implementation of jalik:ufs I made for Angular1, but it will look pretty much the same with Angular2.
http://www.angular-meteor.com/tutorials/socially/angular1/handling-files-with-collectionfs
The guides for ember.js are assuming one has the full ES6 support e.g. http://guides.emberjs.com/v2.2.0/routing/specifying-a-routes-model/ shows using the export default construct and doesn't specify any alternative way to achieve the goals. However the module feature is not implemented in all browsers that ember is supporting.
How can I use these features with a browser that doesn't support modules? How would the code in these examples translate to ES5?
Documentation assumes you are using a transpiling tool, because the recommended tool, ember-cli does. Unless you have good reasons not to use it, you definitely should look into it.
It is, however, perfectly fine to work without it. For instance, without a module system, Ember will map controller:posts.index to App.PostsIndexController. So this should work for the example you linked:
App.Router.map(function() {
this.route('favorite-posts');
});
App.FavoritePostsRoute = Ember.Route.extend({
model() {
return this.store.query('post', { favorite: true });
}
});
You may also use Ember with your own module support. I successfully have an Ember project based on rollup. It does require a bit more work though, to have the resolver find your classes (that resolver link also documents how ember relates does the name mapping). Nothing hard, but you must build a short script to generate registrations.
Edit for blessenm: Ember with rollup
Unfortunately I cannot share this code, but it works like this:
A script scans the project directory and compiles templates by invoking ember-template-compiler.js on every .hbs file it encounters.
A script (the same one, actually) scans the project directory and generates the main entry point. It's pretty simple, if it sees, say gallery/models/collection.js and `gallery/routes/picture.js', it will generate a main file that looks like this:
import r1 from 'gallery/models/collection.js';
import r2 from 'gallery/routes/picture/index.js';
// ...
Ember.Application.initializer({
name: 'registrations',
initialize: function (app) {
app.register("model:collection", r1);
app.register("route:picture.index", r2);
// ...
}
});
It should just map your filenames to resolver names. As a bonus, you get to control how your directories are organized.
Invoke rollup on the generated file. It will pull everything together. I use IIFE export format, skipping all the run-time resolution mess. I suggest you setup rollup to work with babel so you can use ES6 syntax.
I don't use any ember-specific module, but it should not be too hard to add. My guess is it's mostly a matter of setting up rollup import resolution properly. For all I know, it may work out of the box.
You should look into using Ember CLI http://ember-cli.com/
You write your code in ES6 and it transpiles down to ES5.