question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[beta.1] how to handle CSS/SCSS with plugin system and ES6/NPM environment?

See original GitHub issue

Using 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:closed
  • Created 5 years ago
  • Reactions:1
  • Comments:8 (2 by maintainers)

github_iconTop GitHub Comments

3reactions
Lamberthasselcommented, Feb 19, 2019

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.

2reactions
jasonlewiscommented, Feb 9, 2021

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?

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found