search

openmastery / semantic-ui-theme

Theme editor and manager for the Semantic-UI framework
MIT License
15 stars 0 forks source link

Setup Basic Gulp Processing for Building Compiler #6

Open p3nGu1nZz opened 6 years ago

p3nGu1nZz commented 6 years ago

set up basic gulp tasks for creating the compiler.. basically gulp task should execute some JS classes to handle processing

brianespinosa commented 6 years ago

Do we want to use Gulp for this, or is it possible to create as a Webpack plugin?

p3nGu1nZz commented 6 years ago

Yes, I actually looked into this, but didn't specify. The core of semantic as you know relies heavily on gulp to handle all of its processing and building. Along with is massive array of gulp helper packages.

The main reason I used gulp was not try to drift to far from how semantic ui does it, and there existing dependencies.

My plan was to implement the browserify and uglify, along with our yaml compiler, in gulp, so that when we merge into semantic we can swap out the LESS/CSS gulp task with our YML/CSS gulp tasks. Doing this with webpack would require adding many dependenciesinto the semantic package, whereas using gulp would minimize the additional dependencies we require to make this work.

However you bring up a good point. I do feel though that we should support projects that use webpack. Granted its some more work to maintain an additional webpack plugin, but it would allow our users to add our webpack plugin into there existing webpack projects.

Do you think we should include a webpack plugin distribution in our MVP?

Also is there something about gulp you feel is an incorrect choice for building our module?

What advantages do you feel webpack has over gulp?

Right now there seems to be three types of implementations of our theme engine (npm / yarn packages, also feel free to come up with new names, they are a little wordy right now. e could also drop off the UI and just be Semantic-Theme or Semantic-CSS):

brianespinosa commented 6 years ago

I see what you mean. We could do Gulp first as MVP, then shift to Webpack, in parallel at first.

I was assuming that we would be piggybacking on the theme builder's build process but you'd be working on that separately.

p3nGu1nZz commented 6 years ago

Personally speaking i think webpack would have been a much better choice for developing the build system for semantic. The amount of code to make gulp work for semantic is more then the actual code that makes up the core of semantic o_0

Also the gulp process in the root package is for building the example website. By all means use webpack to build out your theme-editor module.. I don't see why this would be an issue. The main gulp build process would just be calling your child build process in your package.json. The technology you use to build your editor is independent as long as it generates a JS module that can be required or imported by a webpage or component you wish to design on.

As a side bar, i have another project i'm working on that uses semantic with electron. Webpack is used to build the main process source code with requires, and my front end semantic uses gulp and babel style import code.. Both seem to work okay together, so i know that if you use webpack as a child build process it will be okay.

Also note that the main gulp tasks and configuration is currently only designed to copy the example files from the semantic ui submodule, and launch an express server. I planned on only using this build directory as a test bed for the JS-Loader package and compiled CSS In JS rules. Future work would roll up your theme editor into a package that we can import into the ./build project. We can use this to test your editor against the example code. I don't see a need for you try to get this to work for the initial release of your editor. For MVP we just need the editor able to export a YAML file with the styles.

The more i think about our project the more this seems like its independent of actual semantic-ui. I would prefer to see this as module you can just add to your project to generate dynamic stylesheet rules from YAML. This might be smarter then trying to merge all of this into semantic itself. i feel like semantic should require our theme package to build its css and rules, rather then embed all of the css processing logic into the core of semantic (as it does currently with LESS. you would think the LESS compiling for semantic would be in the Semantic-CSS or Semantic-LESS packages, but its not. Those are just for static files)

Anyways this turned into a much longer reply then I intended, but i hope it it explains some of our global design a bit better.