Package only method and/or ES6 modules


#1

I recently stumbled upon this post, the directions seem pretty straightforward. My main question is does this replace the package only method of adding files and specifying load order or this complements it? How does this work with .css files which might override each other?


Best practices for structuring files
#2

Yes, it is a better replacement for the package only approach (that I never used :-D).

How does this work with .css files which might override each other?

You cannot specify the load order of CSS files with this. I think you shouldn’t override CSS classes, only for third-party CSS where you have no other option. This makes it just more complicated to reason about styles. Instead use the practices that BEM promote (for example).

In my bigger projects each component has it’s own CSS file that defines the styles of the component. As base I use a CSS Framework (= a package).


#3

Seems I need to merge this with the ‘package’ method for tidiness. A lot of this is also ‘new’ to me so there goes my weekend plans.

How do I export namespaces and consume in different package/scopes?


#4

I’m not sure what exactly you mean.


#5

Thanks for those links. Makes it a lot more clearer. I am going thru 2ality for a better undestanding of the module structure. Having a hard time figuring out things like import { _ } from 'app-deps'; as found in meteor-react-example


#6

@Sanjo is this method likely to stand the test of time (1.2+) of there is a chance MDG will come up with a much different approach when support for ES6 modules hits core? Wouldn’t want the building blocks of my project changed midway thru devt then I end up with nights of refactoring.

I decided to delve deeper into underscorejs to get a better understanding of how to implement these modules.


#7

Ben from MDG (who works on modules support for Meteor) hasn’t released much info on how it will be done.
Some things I can say:

  • The syntax will be the same (ES2015 modules standard)
  • Packages will co-exist with ES2015 modules

#8

Started looking at hit and hit a snag with multiple packages. I seem to have a problem with my System.config({ code.

[Universe Modules]: Module app-deps/main does not exist!
You will probably see other errors in the console because of that

My system-config.js in /packages/app-deps looks like this:

 System.config({
    map: {
        'app-deps': 'app-deps/main'
    }
        
});

The code that is firing the error is at /server/startup.import.js and it looks like this.
“use strict”

import { _ } from 'app-deps';

Meteor.startup(function (){
      //I would like to call a function of app-deps here to check if I have access to it.
});

What am I doing wrong? Could it be the import { _ } part which by my assumption is using underscore but is using lodash as was in the optilude/meteor-react-example which I have borrowed heavily from?


#9

With the latest universe:modules it is:

System.config({
    map: {
        'app-deps': '{app-deps}/main'
    }
});

I think.


#10

I managed to get rid of the errors by using
System.config({
map: {
‘app-deps’: System.normalizeSync(’{app-deps}/main’)

}

});

Also updated universe:modules to latest version.

Now my headache is how to consume functions in Module A in Module B. The readme does not clearly show this and what you have on your example doesn’t go in depth.

Lets say I have this:

Portal ={
    	consoleMessage: function(){
		console.log("Test Portal Message");
	}
};

My packages main.export.jsx has something like

"use strict"
 export default Portal;

How can I get access to this in another package?

In the package only method I would simply have the export the namespace using api.export(‘Foo’);

How do we also deal with global namespace ‘pollution’? Can I keep adding functions to the Portal namespace/variable exported via export default Portal;?