Integration with Meteor.js

[splendido]

Hi all,

I'd like to propose to start an official action for the integration of this awesome User Interface into the Meteor.js, the most popular full-stack JavaScript framework.

I'm starting off based on this very good attempt, about trying to put some order into the packages database for Meteor, started by @dandv.
He also promoted an official integration for FontAwesome opening this issue on their official GitHub repository which so far had nothing to do with Meteor.

Since he wrote his proposal in a very clean wording, I ask you to read it carefully since it can be exactly the same for Semantic-UI.

At the moment there are at least five different packages all simply wrapping semantic source code.

@lumatijev, @nooitaf are the maintainer of the most stared packages: I hope they'll also agree about taking a single official action for this.

My proposal, if you agree, is as follows:

• verify whether the name 'semantic-ui' is still available for a new Meteor organization
• create the organization on meteor.com (it could be me if you wish, but not necessarily...)
• add @jlukic among the people belonging to the organization (requires him to create his own developer account) and possibly other people from both semantic-ui and meteor
• figure out the best pattern to follow the make it as easy as possible to publish the official wrapper package (possibly on the lines suggested by @dandv)
• publish the needed packages (css, less, sass, fonts, no fonts, etc...)
• contact all other developer who published similar packages and kindly ask to mark them as no more maintaned (so to have them disappearing from the list on Atmosphere)
• keep up the collaboration to maintain the published packages at best

Hope this make sense also to you...

Please let me know what do you think about this!

[lumatijev]

I like your idea and I'm willing to back it up.

[jlukic]

Thanks great write-up. Glad to see meteor integration kicking off. Let me know whatever assistance you need.

Once code starts forming I can add you to semantic-org and move over the repos.

I also encourage everyone to fill out the form in the readme to sign up for slack access. Will be useful for organizing.

[splendido]

Great! Good news then ;-)

what would you prefer as the Meteor organization name?
'semantic-org' or 'semantic-ui?

Consider that publishes packages come in the form 'organization:package_name'

so it could be something like:

• `semantic-org:semantic-ui
• semantic-org:semantic-ui-less
• etc.

or:

• semantic-ui:css
• semantic-ui:less
• etc.

That's mostly up to you I guess!

[jlukic]

We already have an organization set-up for Semantic-Org on GitHub. So I think it would make sense to keep it consistent on atmosphere. I'm not too familiar with naming conventions for Meteor packages. So whatever pattern you see most commonly used, I think is fine.

[splendido]

ok so I'd say lets go for semantic-org as the organization name.

Then it could be:

• semantic-org:ui
• semantic-org:ui-accordion
• semantic-org:ui-button
• etc.

But just in case we'll decide to public also single modules... otherwise semantic-org:ui, semantic-org:ui-less, etc. might be more than enough ;-)

Thoughts?

[nooitaf]

Just registered semantic as organization.
semantic-ui is not possible because dashes are not allowed.
Following iron:router's example i would suggest semantic:ui as package name.

• semantic:ui
• semantic:ui-button
• semantic:ui-accordion
• etc

As the semantic source uses less i would suggest dropping css and just use less by default.
On deploy/running it will be converted to css anyway.

[jlukic]

These seems perfect. I think the ui- convention makes searching for components simpler.

[splendido]

Hi @nooitaf!
So please add @jlukic, @lumatijev and @splendido to the organization

@jlukic please register yourself as a developer on meteor.com (top right corner...) possibly keeping your username ;-)

[nooitaf]

All added :)

[splendido]

well done!
now please wait the others' consensus before publish anything.
Lets not burn semantic:[email protected] with a mistaken publish ;-)

[lumatijev]

Agree with that. We should be careful with publishing since there is no way to fix mistake without increasing version number.

Should we all work in Semantic-Org's repositories? @jlukic
Or personal repository and than publish in name of organization? I think it's better to work in same repository and have more branches for each package so that it can be easier to maintain?

[jlukic]

I've given invites to all those currently in conversation to join Semantic-Org. You should also have complete admin access to Semantic-UI-Meteor repo. I'll trust it to your organizing guidance. You should also have the ability to invite and add additional members to your team if you need to do so.

[nooitaf]

I am still trying to wrap my head around a good way/balance of usability and advanced settings.
Sometimes you just want to drop in a front-end framework and go on. Having a lot of setting files would just complicate things. So maybe make semantic:ui just work out of the box and only if you add some special json/less at special positions (client) or have a config in javascript it would override stuff.

I agree that we should have a solid system (clear for the user) before we publish.

@jlukic nice :)

[lumatijev]

Maybe we could make semantic:ui to work out of the box as you said with no customization options. And lets say semantic:ui-custom or something like that with customization options?

[lumatijev]

Also, I agree that we should only use less source as you mentioned before.

[splendido]

Thanks @jlukic!

So welcome on board for the Meteor integration to all of us!
Happy to be with you! ;-)

What do you think about bringing on the discussion as a first issue on the newly created Semantic-UI-Meteor?

[nooitaf]

@splendido go for it ;)

[dandv]

@splendido: Thanks for taking the initiative! I'm very glad to see my official integrations effort picking up speed!

I've also squatted the semanticui and semanticorg organization names, just in case, and added @jlukic, @splendido, @lumatijev and @nooitaf to them. But happy that we have the semantic namespace. Much better than the moment situation. (Who took that username?)

I'll let you guys run with this! Glad to have been of help.

[splendido]

Hey @dandv, it is thank to you if I started this!
I completely agree with your points so far ;-)

...I've just updated the link as you asked.

We'd be happy to hear also your opinion about this discussion here

Tnx again, it's a pleasure to side you!

[ghost]

FYI - I noticed the comment about not doing a mistaken publish and burning a version number. In Meteor 0.9.3 they added special semver support for wrapped packages to allow you to keep the normal semver consistent with a release even if you did make a mistake :) For any sort of wrapped package you can set the version to "x.x.x_x".

You can read it on the blog at https://www.meteor.com/blog/2014/09/25/meteor-093-packaging-system-updates.

[splendido]

Yeah, that's true. Thanks for remembering us.
The thing is, IMHO, there is no hurry at the moment so the best would be to have one single shot publication right at the first time to keep things as clean as possible.

I think it is not only about making a silly mistake you can revert with another publish like @1.0.0_1
but it is also about having reached an agreement on what to publish: CSS vs LESS, e.g.

I wouldn't publish a @1.0.0 with CSS files and then a @1.0.0_1 with LESS files for any reason ever ;-)

[zimme]

semantic:ui - everything that's necessary to get basic semantic-ui going. This should have less as dependency and use semantic-ui less source directly as @nooitaf said.

semantic:ui- - semantic-ui components/modules/whatever, should have semantic:ui as dependency

semantic:ui-less - should have weak dependency on semantic:ui and make the necessary setup if semantic:ui package is avaiable. This package should also have it's less files use .import.less to make
sure it's not compiled with the less package automagically but only intended to be used by importing the files into your custom less files.

semantic:ui-less- - Same as above...

Something like this maybe?

[zimme]

Another approach is

semanticui:full
semanticui:small
semanticui:....

[splendido]

I like the idea to have a base package containing all .less.import files!
Perhaps it would be better to call it semantic:src to keep semantic:ui as the main package with depends on the first one importing all source.

Then semantic:ui-<component> should imply the source and then have a number of week dependencies so to grant the correct import order of other components (in case this is necessary)

[zimme]

What i meant was

semantic:ui is depending on the less package and adds .less files that gets automagically compiled as css

then we would have semantic:ui-less which would have .import.less files instead

[lumatijev]

We don't need "-less" suffix if we will only work with less and not with css. It will be compiled to css anyways so there is no need to state less in package name. It will be easier to remember and more consistent to have only lets say semantic:ui as main package.

[lumatijev]

Keep it simple and as short as possible. I think that is important enough.

[splendido]

Ok, same thing.
I'm sorry I got it wrong at the first read... :-(

[dandv]

This may help - I've improved my Meteor packaging scripts to test and publish multiple packages out of one repo - https://github.com/RubaXa/Sortable/tree/dev/meteor

[unity3diy]

thanks :) 😸

[jlukic]

Hey its been a week, just want to check in with everyone. See what I can do to help get the ball moving again.

[dalgard]

👍

There are various packages with Semantic UI for Meteor but there's a big need for a canonical way of making customizations to the default styles of Semantic.

[PavanKu]

Guys, can anyone give some update about meteor integration? what is needed to make this fast?

[nooitaf]

@PavanKu Main Discussion is at Semantic-Org/Semantic-UI-Meteor#1

@splendido did a good start on how to make publishing easy for the maintainer, but the 'theme/customization' issue is still unclear i think.

[dalgard]

The way I understand it, theming is mostly about overwriting variables in the LESS files of Semantic UI.

Does LESS have the same function as Sass does, where a variable can hold a default value, which may be overridden anywhere in the code, even before?

In that case, would it be a feasible way to go having a LESS file with variable overrides somewhere in app space and then compiling it before the LESS files in package space during the build?

I have no idea how or if the LESS module deals with uncompiled LESS code in packages (probably it doesn't), but maybe this should change in order to support our use case here.

[splendido]

We're waiting @jlukic to finish the integration PR. He already started to merge it manually on the meteor branch but I guess he's very busy these days with the 1.7.x releases going on...

After this, we should get official packages with plain CSS style files.

The problem with the LESS variable customization is better summarize in this post by Jack where it make clear the inheritance problems with LESS with the current structure of the project.

The good news might be that, once there will be a pacakge.js file on the master branch, if you download the Semantic bundle, customize it as you wish, and eventually build it, you can simply simlink the Semantic folder under your app's packages folder and your customization will be imported as a meteor package.

I'm more and more convinced that publishing different compiled themes or trying to find a way to let it easily customizable might be useless in view of this possibility.

Basically you could do something like this:

meteor create myApp
cd myApp
mkdir packages
cd packages
git clone https://github.com/Semantic-Org/Semantic-UI.git
cd Semantic-UI
....your customizations here ...
npm install
gulp install
cd ../../
meteor add semantic:ui
meteor

What do you think about this?

[serkandurusoy]

I spent the better half of this day trying to come up with a good strategy to include the official (as of yet) package and apply theming.

I certainly did want to avoid using gulp grunt bower etc and the likes. I love meteor for its simplicity and its isomorphic nature where I don't need to master different tools for different tasks and I love that it is itself perfectly capable of building various sources.

Meteor goes to great lengths to integrate everything into a single meteor command. No node install! No mongo install! No cordova tooling install! No android!... You see where I'm getting at.

If only we had means to meteor add themes, or perhaps a starter theme (css/less/sass) that we can copy over and begin hacking away...

You know what, I'm almost two years into meteor development, and I'm still dead-scared of node, npm, gulp, bower...

There... I said it...

;)

[jemgold]

@splendido is there anything we can do whilst waiting for #1607 to be merged to get Semantic UI working in Meteor with variables & customization etc?

[jlukic]

You can always drop in a zip file.

[splendido]

Hi @jongold,
what do you mean with

with variables & customization etc?
if you're thinking about a LESS version, feel free to investigate. Keep in mind that, from the previous discussions it seems hard to get a LESS version properly working because of a number of variables overwrites done on a component basis.

Unfortunately I'm not going to have time to look also into this: getting the canonical CSS packages (auto)published would be my personal goal... :(

Any news @jlukic on the merging process of meteor-integration?
Please let us know if there's something you're not comfortable with, of if you simply don't have enough time to look at this now.

[serkandurusoy]

Is there a suggested way of using one of the pre-compiled templates to use as a base for a custom theme?

Of course I'm asking for a way of doing it within meteor, not by cloning the semantic-ui repo.

Basically, what next after meteor add nootifaf:semantic-ui?

I don't quite understand what zip file to drop in where.

[dalgard]

In the project I'm working on, I'm simply overriding whatever parts of the Semantic UI basic theme I don't like with simple CSS declarations. It is working okay, even if it's a bit bothersome and doesn't produce the nicest code...

[serkandurusoy]

a bit bothersome and doesn't produce the nicest code

nicely put :) Ok, I guess it at least seems to be the most convenient among the alternatives.

[splendido]

@nooitaf had a semantic-ui-less package (I never tried).
Perhaps someone played a bit with it? Was it doing its work? Were customization possible (to some extent)?

[nooitaf]

@serkandurusoy i would suggest not using a package but just use the src folder from the semantic-ui source and add the less package, so it gets compiled by meteor. I didn't try it yet, but it should work.
nooitaf/meteor-semantic-ui#27 (comment)

The semantic-ui-less package is deprecated, because the 1.0 source works differently somehow.

[jlukic]

@splendido I'm trying to rewrite the gulpfile while doing the meteor integration. I want to move all the tasks to individual js files and use requiteDir(). I also need to update gulp release to create GitHub tags when deploying to each of the 50+ component libs.

If everyone prefers I can just drop in a package.js file and make things available immediately. I have not personally done any testing with using SUI package in Meteor however.

I'd prefer to hold off until I can find a way to make LESS customization/build tools available in an easy to use set-up within a meteor package.

I'm trying to get 1.8.0 out the door today. You can see the Release Notes to see what it covers. I need to spend the rest of the afternoon documenting some changes, doing some sanity checks, and other tedium.

[serkandurusoy]

@nooitaf thanks, and thanks for providing the semantic-ui package all this time as well.

But in light of @splendido 's comments:

Keep in mind that, from the previous discussions it seems hard to get a LESS version properly working because of a number of variables overwrites done on a component basis.

I feer that path may lead to even more problems.

Also, I will lose the convenience of meteor update.

As it currently stands, I fear there are two unquestionable options:

• Use semantic-ui sources to build your theme as a standalone project and than include it in meteor
• Or use the package from meteor and stick to whatever it provides

Yes there is a vast middle ground there, but they are all kind of hacks, overwrites and non-standard ways of achieving the goal.

[serkandurusoy]

I'm trying to get 1.8.0 out the door today.
@jlukic 👍 for that.

The discussion around Meteor integration and my current frustrations do not overshadow my appreciation for what you've been doing both with the framework itself and your embracing response with third party integrations. Kudos for that!

[splendido]

I second @serkandurusoy in complimenting with Jack!

@jlukic, perhaps dropping in the package.js file into the root folder wouldn't be a bad idea?
...this way we can start publishing the first semantic:[email protected] (by hands) and enabling the possibility to whom is interested in custumization to follow the small guide I posted in this previous post of mine.

So we can start picking up some feed-back on it.

What do you think?

[splendido]

Before getting able to publish a customizable LESS package I really think we'd need to waint until things get improoved a bit on this side.

There's a lot of active discussion about changing the way packages work, especially about letting the possibility to configure them before load time (in our case with SUI this would mean letting the possibility to specify some variables overwrite before LESS compilation...).

See for example this card on the official trello roadmap or this discussion and this one on Meteor Community

In the meanwhile I suggest to take a look at how Nemo64 allows for customization in his bootstrap package
As I already said, unfortunately, I'm not going to have enough time to explore this path, so please feel free to go ahead on this.

[jlukic]

I just released 1.8.0.

Will weigh this all next week. I think all package managers are having the same issues. Build tools are locked inside PM folder which is treated akin to a temp/ directory. See #1385

I think the solve is the install process dropping the entire payload somewhere else. Preferably whatever it assumes is project root.

[splendido]

Congrats on the 1.8.0 release!

[splendido]

For the Meteor package, please consider that the package.js file is used only once when you run meteor publish:

at that time the list of added files is picked up from the package folder, bundled with isobuild and uploaded to the packages server.
Later on the package.js doesn't exists anymore.

Hence the only needs are:

1. have the compiled files under the dist directory correctly linked from inside the package.js file by means of relative paths
2. the compiled files exists at the moment of running meteor publish

So, to publish the SUI Meteor package, there are no build processes involved if you ensure to push compiled files to the repository everytime you make a new release.
Once autopublish.meteor.com will receive the notice, the repo will be cloned and meteor publish run from its root folder.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.