‘a new beta’ … good to hear it!
Now I try to convert a package full of Blaze templates to api.mainModule
aproach but I can´t figure out how import
/ export
a Blaze template.
‘a new beta’ … good to hear it!
Now I try to convert a package full of Blaze templates to api.mainModule
aproach but I can´t figure out how import
/ export
a Blaze template.
Make sure your package has api.use("templating")
, and try putting import "./the-template.html"
in the main module? While I hope that works, it’s worth mentioning that this is somewhat uncharted territory, so any feedback you have about working with templates in modules will be much appreciated!
To update to the latest beta release, run the following command in your meteor project:
meteor update --release 1.3-modules-beta.1
Changes: https://github.com/meteor/meteor/issues/5788#issuecomment-165935104
@benjamn I was just wondering if you have any new info regarding lazy loading on new meteor apps? I’m getting ready to record a screencast on migrating a Meteor 1.2 app to 1.3 and that would factor into it a bit.
In an app, in the case of aurelia
, we need to import an npm module as follow :
<body>
<script>
System.import('aurelia-bootstrapper');
</script>
</body>
but aurelia-bootstrapper
doesn’t exist in the source browser as we can’t import it from a js file.
@benjamn, as indicated in the release notes, Meteor 1.3 will introduce Ecmascript async
and await
keywords. Since Meteor used fibers
to runs asynchronous code in a synchronous style until now, I wonder if these two strategies will co-exist for some time, and if the new keywords will be recommended over usage of fibers
(I‘m also not quite sure of the consequences of this series of commits but I guess that’s related). Concretely will we have to insert a await
keyword in these kind of statements:
let doc = Docs.find(docId);
?
How do we find which commit on GitHub 1.3-modules-beta.1
is made from? EDIT: After cloning, I see the tag release/METEOR@1.3-modules-beta.1
, but the strange thing is I don’t actually see this tag while in GitHub’s UI, which is where I was originally looking.
Now that users populate node_modules
themselves, are there any implications of using NPM v2 vs v3?
meteor update --release 1.3-modules-beta.1
does this include the speedups to load time that was in the previous
METEOR@1.2.2-faster-rebuilds.0
I’d prefer to keep fast builds as #1 priority…
Yes, 1.3-modules-beta.1 contains the change in 1.2.2-faster-rebuilds.0
Has anyone managed to get redux-devtools working with 1.3?
I do:
npm install redux-devtools --save
then:
import { createDevTools } from 'redux-devtools';
but in the browser console I just get:
Uncaught ReferenceError: global is not defined
We released 1.3-modules-beta.2
today, with the following changes:
To try the new release, run:
meteor update --release 1.3-modules-beta.2
meteor update # to update the react and jsx packages
Just to clarify, after upgrading I should remove meteorhacks:npm, re-add npm-container and install everything via npm install
?
Good question. I too would like to know the answer on this.
@csiszi No, in fact, you should just entirely remove meteorhacks:npm
, then, at the root of your app, run
npm install whatever-package-you-want
and finally in your app code
import something from 'whatever-package-you-want'
There’s no need for meteorhacks:npm
anymore (and you can delete npm-container
).
Awesome, thanks!
I currently use a package.json
with some devDependencies
(for some linting tools) and I noted in the current 1.2 docs that:
For compatibility with node.js tools used alongside Meteor, any directory named node_modules is not loaded anywhere. node.js packages installed into node_modules directories will not be available to your Meteor code.
So this will be different in 1.3. If I move all my meteorhacks:npm
packages into package.json
and run an npm install
then Meteor will now be reading everything in node_modules
. I guess that as my current modules are devDependencies
that this actually is okay.
@timfletcher That statement is essentially still valid with a new exception: files from node_modules
won’t be loaded automatically, just as before, unless you explicitly load them with an import
or require
statement somewhere in your code. If you never import anything from node_modules
, then those files will never load. However, if you have files outside of node_modules
that you aren’t importing anywhere, then those files will be loaded automatically by Meteor unless they are inside any folder named imports
.
I’m using various packages that are wrapping npm modules [1]
I’m seetnig errors like:
Uncaught ReferenceError: module is not defined
app.js:36 Uncaught TypeError: Cannot read property ‘Handsontable’ of undefined
here:
module.exports = exportModule(
this looks like node code for the original package to me.
I understand meteor now has a new way of requiring npm packages, but if the original npm package itself can’t find module
… how do we work around that?
OK so 1.3 seems to break wrapper packages, so I’m trying to debug how to use the new native meteor npm import features.
for others checking this thread, its important to do this:
mkdir node_modules
then
npm install whatever-package-you-want
so in my case I have added an npm package, but I am getting an error on trying to import it.
import Handsontable from 'handsontable';
Cannot find module ‘handsontable’
maybe that package itself is a bit funky as there was some discussion about npm support.
My question is - how do I figure out how to fix the import?
either the module identified by the main field of the package.json file, or index.js
The original module’s package.json has no main
field and there is no index.js
So possibly that breaks meteor’s import feature?