[beta.1] how to handle CSS/SCSS with plugin system and ES6/NPM environment?
See original GitHub issueUsing a system like NPM with Webpack/Rolllup provides seamless way to bundle all the plugins/dependencies you’ll need for your project. For example, if you compile this:
import { Calendar } from '@fullcalendar/core';
import timeGridPlugin from '@fullcalendar/timegrid';
document.addEventListener('DOMContentLoaded', function() {
var calendarEl = document.getElementById('calendar');
var calendar = new Calendar(calendarEl, {
plugins: [ timeGridPlugin ],
defaultView: 'timeGridWeek'
});
calendar.render();
});
…then all the necessary JS will be bundled together: the core
js, the timegrid
js, the daygrid
js (which is depended-upon by timegrid)
However, such a system doesn’t exist for the CSS that each plugin depends on. Currently, you’ll need to manually include the following CSS files on your page somehow:
node_modules/@fullcalendar/core/main.css
node_modules/@fullcalendar/daygrid/main.css
node_modules/@fullcalendar/timegrid/main.css
(and it’s important that they’re ordered correctly)
The conventional wisdom for distributing reusable JS plugins that rely on CSS seems to be to leave it up to the developer to decide how they want to deliver the CSS. They can concatenate it together with the rest of the app’s CSS, they can @import
it from their sass files, or do something else.
But this technique puts a significant burden on the developer when using a system like fullcalendar’s which now has a network of plugins that might rely on each other in arbitrary ways. You’re forcing the developer to understand the dependency graph.
What should we do about this?
- keep it as-is. the developer should be responsible for including the CSS files
- have each of fullcalendar’s plugin files that require CSS do a ES6-style
import
and require the developer to have a CSS loader in their build system. CKEditor does something like this. - bundle the CSS within the JS files. have a giant string with CSS that gets attached the document dynamically via the JS. or some other technique of this sort. we’d need to prevent a FUC though.
Thoughts? Please provide pros and cons of each approach.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:8 (2 by maintainers)
Top GitHub Comments
I think it will be better to keep it as-is. It may look a bit dirty but this approach is the most transparent, a developer could easily understand which styles he/she’s importing. Moreover, some developers may want to write CSS for Fullcalendar from scratch, so it’s important to keep the opportunity not to import native styling at all.
Why did this mentality change in v5? How are we able to completely customize styling now as it appears Full Calendar just straight up imports all the styles?