Making the package importable [Meteor]

[peterchoo]

Hi all,

I'm hoping to be able to use the LESS stuff in my application, and after a comment from @splendido on crater, I thought I'd have a quick look and see what I could get done.

Here is the initial set of changes I've made to the package to allow me to import it into a Meteor application.

The changes I made are fairly lightweight, but as far as I can see will not allow for external themes to be applied over the top, but it's a start! Here are the steps I took:

1. SemanticUI-LESS$ find . -type f -name "*.overrides" -exec mv "{}" "{}".import.less \;
2. SemanticUI-LESS$ find . -type f -name "*.variables" -exec mv "{}" "{}".import.less \;
3. Create default theme.config file (I changed themes/ to themes, and site/ to _site, and theme.less to theme.less.import.less)
4. Change theme.less totheme.less.import.lessortheme.import.less` (I used the former to follow the pattern I used on the overrides/variables files)
5. Update package.js to have .import.less on the files changed, and add theme.config to the addFiles array.

If you're not familiar with the less processor in Meteor, it will ignore files ending .import.less.

The package now processes all the remaining .less files in the order they are in the array provided to api.addFiles(). This order may need changing to match the build order if some parts of the LESS depend on others. My knowledge of LESS is rather shallow, and I've only really had a short look at the gulp build stuff.

A brief experiment has shown that I cannot set something like @button: 'amazon'; and have it affect the build process inside the package. My current plan is to find out if having the Semantic-UI-LESS package include only the default theme, and reference the main repository for any theme examples. If that works (I can't see why not), then my next investigation will be into whether I can use and imply the main package in a theme package and add my LESS theme into that as a custom package... we shall see!

Anyhow, this is the start I've made, let me know what you think etc :)

[splendido]

Hello @peterchoo!

I think renaming everything to .import.less is a really good start! :)

I also think, which IMHO is the obvious use case, the theme.config and theme.less should be put into the app folder by the developer to select the theme she prefer.

I'd say we might try to understand wheter from inside these files we could import something like

packages/semantic_ui_css/something.import.less

this is somehting like the path used to download the assets to the client side (lets check the path from where fonts are downloaded on the client).

If this is the case, it might be quite easy to write a couple of templates for theme.config and theme.less.

Otherwise, the wiser approach so far I can know about is the one used by @Nemo64 for his nemo64:bootstrap you can find on this repo

Perhaps @Nemo64 would be willing to give us some help? :-)

[jlukic]

There are explicit locations for you to define your variables.

• If you're changing a theme, it's theme.config and it's per element.
• If you're modifying an element variable for your site it's site/elements/button.variables
• If you're adding css overrides to an element it's site/elements/button.overrides
• If you're creating a packaged theme it's themes/theme-name/elements.{variables,.overrides}

The same variable name may have different meaning in different contexts @margin may mean a different thing to a button than to a menu.

Please read the theming overview for more details.

You can't import the files then define the variables after the fact, because the project uses variable scoping.

[peterchoo]

@jlukic Thanks for the clarification, I wasn't aware of the variable scoping. With the restrictions outlines above, it doesn't sound like including a Semantic UI LESS package in the manner I adjusted it above will give you anything other than the default LESS compiled into a CSS file. I had a feeling the order in which files were processed was important.

It seems to me that the best approach would be to do what @splendido suggested above, and look at @Nemo64 's approach, creating some custom middleware to compile the LESS files in a way which would on it's own provide the same output as the css available in the semantic:ui-css library, but also add a compile time step to process the LESS files and intelligently insert the override/variable files from either a wrapper package, or the application the package is included in.

When I first looked into this, I was studying how @Nemo64 did it with the bootstrap stuff, it's an area I'm not too familiar with in Meteor, so any help provided for that would be very much appreciated.

[splendido]

@peterchoo could you please make reference to the Meteor platform within the OP title?

[peterchoo]

@splendido Your last comment has removed some blinkers for me, in that I'm no longer so sure that appending .import.less to everything is such a good idea - What about the other ways of including this repository? Is this for Meteor only, or will this also exist on bower/npm? We could just leave the files as .overrides and .variables and manipulate them in the build process.

The best course of action now would be to write some middleware akin to @Nemo64's bootstrap - having looked more into it, this would take a sub-package containing the data, has a configuration file for the list of all files within the package, and then for all these files gets the content, and saves it to one output file, which the application's inclusion of the less package consumes. It also replaces any @import statement with the actual data from the file.

This sounds like an approach we can use, but it would need to be able to process the files in the way @jlukic outlined above. We would also need to figure out how we can include external sources. I'm wondering whether we can do this in one step, or whether the package can provide a set of files for a second build step?

I have also been looking at the Meteor LESS package compile process and it takes advantage of Fibers/Futures. I haven't had any experience using them myself, but I would assume that we could use them here so that we only generate the compiled LESS file for the applications less package to compile for us. We could api.imply('less') in this package, or say "Do meteor add semantic:ui less to add both packages required to use the less theme".

This would give us a package which would on it's own create a less file using only the defaults. If we get the compile process right, users could have a file in their project which acts as theme.config so that they could override themes for specific bits (no file = defaults for all) which would let them use any of the pre-defined themes in Semantic-UI already.

We could also provide a template package for adding custom themes, which would make all the theme files added available to the compile step. How exactly we go about the compile step I don't know. I think we will definitely have to use Futures, but with my inexperience I can't say how just yet. My gut feeling is that we can create an in memory file cache, and when all files of config type have been processed, we can then go through the build process for all the files in definitions/ and apply any theme files over the top. I've excluded site stuff from this process, as we could just leave that to the user to override in in application .less files.

Your thoughts?

[jlukic]

The npm package includes a complete build script, I spent quite a bit of time working on it, and for me this is the preferred method of consuming the themable Semantic UI. You can read more about the original plan in this thread

npm install semantic-ui

I'm a bit unfamiliar with how api.addFiles() actually affects a package's use with Meteor. Are those files exposed somewhere? How does a developer choose which files to include on which page? Are you able to edit files in meteor packages (variable/theme files)? Most likely I'm guessing these suffer the same issue as all PMs which is they treat the whole shebang like a temp/ folder and clear it on updates. This was the original reason all the NPM tools were written, and that pathway accounts for it.

I'm not sure how i'd go about rewriting those tools for every platform (Angular, Ember, Meteor) etc.

[peterchoo]

Meteor itself has an automatic include process, i.e. if the less package is included in your application, every .less file in the folder structure (with the exception of anything in a package) will be processed. This has a down-side as the order in which the files is evaluated is a bit complex. There is logic behind it, but unless you know it exactly you cannot guarantee you've got it right.

Inside a Meteor package, however, the api.addFiles() function is what lets Meteor know which files are to be evaluated/executed by the application. In a package you must explicitly say which files you add, and in which order. The Package.onUse() function is what is called when a package is evaluated by the Meteor. This checks which packages (if any) the package relies on (as defined by api.use()) and which packages are implied (api.imply() means if you use this package, you use the implied packages as well).

Each time api.addFiles() is called, the file (or array of files) is evaluated, in that specific order. You can optionally pass a second parameter to define where the files should be evaluated, server, client, web.browser and web.cordova.

With all that said, the files are not exposed anywhere, and you cannot edit them. That's why in my comment above I suggest that once we find a middleware solution which would work, we have a sample package for applying a theme on top using that same middleware.

[jlukic]

Anyone willing to fork the readme and write a short explanatory note slash call for help? I'm a bit clueless on how to word it given my remedial knowledge of Meteor practices.

https://github.com/Semantic-Org/Semantic-UI-LESS/blob/master/README.md

[splendido]

Hi guys,
Something is moving! See this hackpad

And @flemay come out with a package inspired by the one proposed by @Nemo64 for Bootstrap.

[flemay]

@splendido Thanks for pointing out! :)

[splendido]

👍

[splendido]

@jlukic, @flemay, @emgee3, @Nemo64
...I think that working together would make for a great SUI LESS package! :-)

[flemay]

@splendido out of curiosity what is missing from my package? :)

[splendido]

@flemay, it's not the official one! ;-)

...all other SUI packages were officialy integrated by @jlukic under Semantic-Org and published on atmosphere under the semantic namespace.
Whatmore they are now automatically updated through autopublish.meteor.com at every new release.

We've reserved semantic:ui as the package name for the official LESS version and it's still to be published...

It might be that your package is just fine to be elected as the official one, but it should at least migrated under some official umbrella :-)

[jlukic]

@flemay The only concern is on automating updates to SUI.

I think the best place to start, if you are comforable, is giving you an official semantic-org repo where you can move your files, and then giving you access to the atmosphere organization for semantic so that you can publish the package as semantic:ui

After that we can discuss automating updates from the main repo. This just means updating our build script to push the src/ to some folder in the meteor project when the main repo is updated. The build script will automate the git commit of the changes and also tagging of new releases in git.

You can take a peek at what we have currently here. This manages release of the less and css only repos.
https://github.com/Semantic-Org/Semantic-UI/tree/master/tasks/admin/distributions

[flemay]

@jlukic I am more than happy with the idea! :)

I also have automated the process of getting version X of Semantic UI and generating the files into the packages. So part of my packages has been automatically generated.

[jlukic]

I've invited you to our team on Meteor 'semantic'.

I think this is what we can do next

• Migrate meteor-semantic-ui to semantic-ui-meteor
• Set up autopublish on http://autopublish.meteor.com/ for the new repo
• Change semantic:ui atmosphere package to point to new semantic-ui-meteor GitHub endpoint (previously it was semantic-ui-less)
• Finally have a decent meteor less package available officially.

Thank you flemay for your hard work. If you need any help with autopublish talk to splendido, he's the one who made it.

[splendido]

👍

[flemay]

Thanks you @jlukic!

I will also need to create a new repo for the data and a new meteor package.

[splendido]

@flemay, the repo already exists and is semantic-ui-meteor and the package name that will be used is semantic:ui (... and its creation and updates will be managed by autopublish.meteor.com)

[splendido]

The big part of the work, from what I can see, will be to create a grunt task to replicate the src folder of main SUI package inside semantic-ui-meteor possibly renaming .less files to .import.less ones when required.
This would replace the need for your flemay:semantic-ui-data package.

Once this will be ready the code you have inside your flemay:semantic-ui package should be migrated into semantic-ui-meteor.

We'll then probably have to agree/confirm on the file names and folder structure to be used under the client forlder of the target app, but this won't be a big deal...

[splendido]

Other parts which should be automatically generated/updated by a grunt task could be this one, this one and this one

[flemay]

@splendido I have made a gulpfile to rename/etc the files. :)

I think I don't understand how it would work without flemay:semantic-ui-data. Would you like to explain your thoughts? :)

[splendido]

...perhaps I'm missing something, but wouldn't be enough to have the src files in the same package and use the very same code you have in flemay:semantic-ui-data to get the asset files to copy over to the app's client structure?

[flemay]

If there was a way I would've taken this approach for sure unless I am not aware of it.

From nemo bootstrap-data:

"The reason this package exists is to provide a workaround for the limitation, that meteor does not allow static assets to be accessed in a build plugin. It is however allowed to 'use' other packages in a plugin and this other package can than provide static assets (which is what this package does)."

[jlukic]

with meteor pipeline limitations

[jlukic]

So what's left to get this at semantic:ui?

[flemay]

I haven't moved the code yet.

We need to create 2 repos and 2 packages.

And how to integrate with autopublish.

[jlukic]

I've added a new repo that you can push to semantic-ui-meteor-data

Once both repos are set up and to your liking I can turn on autopublishing.

From what I understand it works off of GitHub tagged releases.

I've given you access to the semantic org on Atmosphere as well.

[flemay]

Thanks @jlukic I will push today/tomorrow! :)

[flemay]

@jlukic @splendido Do you guys have preference about the package version number? Would you see semantic:ui v1.0.0 or semantic:ui v1.12.0?

[Semantic-Pusher-Robot]

I think match the current version number

Sent from my iPhone

On Apr 18, 2015, at 6:29 PM, Frederic Lemay notifications@github.com wrote:

@jlukic @splendido Do you guys have preference about the package version number? Would you see semantic:ui v1.0.0 or semantic:ui v1.12.0?

—
Reply to this email directly or view it on GitHub.

[splendido]

yeah, defenitely the current SUI version to keep everything aligned!

[flemay]

I just published semantic:ui and semantic:ui-data :)

[splendido]

👍

[splendido]

what about the gulp tasks to update the two packages?

[splendido]

@flemay, could you make flemay:less-autoprefixer a dependency so that mrt add semantic:ui would be the only thing to run to add the package?

[flemay]

@splendido would you mind to test without flemay:less-autoprefixer? :)

I haven't yet open sourced. I haven't had time to look at autopublish yet.

[flemay]

If you find a way to do it without flemay:less-autoprefixer it would be better but I haven't found a way.

[splendido]

@flemay, I'll try to test it this evening (in about 12 hours...)

[flemay]

@splendido Cool thanks! What I do understand about packages is even if a package requires less it does not mean your application will compile less files automatically. You would also need to add the package if you want your application to have it.

[splendido]

well, there's a difference between having api.use or api.imply inside the package.js file.
api.imply should have the very same effect of adding the package to the application.
...but I never tried it specifically for build plugins

[flemay]

You are right! :) Just tested it and it worked! Thanks!

[flemay]

@splendido I have updated github so if you could test locally (from the source) it would be very good and if you are happy we can then publish them on atmosphere! :)

[splendido]

I've just cloned semantic:ui and semantic:ui-data into a project's packages folder, I've created an empty custom.semantic.json and It gets filled up...

...but nothing else is happening :(
No additional files are added to my project!

Am I missing something here?

[flemay]

Maybe the README is not good enough.

Basically, the package will not generate the files straight away. It allows you to select what you want first. You will need to modify the content of custom.semantic.json (it has to be different than .custom.semantic.json).

[splendido]

I'd say a first default generaion would be more intuitive ;-)

[splendido]

I removed a component and it worked!
...but then I changed the theme from default to github and got this error:

client/theme.import.less:15:1: Less compiler error: 'themes//default/globals/site.variables' wasn't found. Tried -
client/themes/default/globals/site.variables,/home/luca/Tests/test-sui/client/themes/default/globals/site.variables,themes/default/globals/site.variables

[flemay]

would you like to open a feature request for generating the default by default? :)

[splendido]

you mean a new issue on Semantic-UI-Meteor?

[flemay]

yes.

And regarding your issue, maybe you need to have a look at your theme.config.import.less.

[flemay]

btw thanks for testing! 👍

[splendido]

issue opened

...for my bug I'll test to change the theme.config.import.less accordingly...

Tnx!