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.

Support reconfigurable modules via "@forward ... with"

See original GitHub issue

Edited by @nex3

The current plan is to add a with clause to @forward. This would work like the same clause in @use, except that unconfigured variables or variables set with the !default flag would still be configurable by the modules loading the module in which the @forward appears. For example:

@forward "unopinionated" with (
  $hue: 0 !default, // Can be overridden by upstream users.
  $saturation: 50% // Cannot be overridden by upstream users.
);

I’ve been moving my Sass packages over to the module system, but I keep hitting a problem I can’t figure out. I usually have a central set of configuration variables that need to:

  • be configurable by users
  • be used by all the internal modules

But any time I make an internal file available to other files, I lose the ability to take user-configurations:

Error: This module was already loaded, so it can't be configured using "with".

I’ve tried adding duplicate !default settings in each file that needs, but then I get:

Error: Module sass/_config.scss and the new module both forward a variable named $setting.

As far as I can tell, everything that uses a particular default variable has to live in the same file?

Is this how it’s meant to work? How would you recommend handling global package config shared among partials?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:13
  • Comments:23 (14 by maintainers)

github_iconTop GitHub Comments

4reactions
nex3commented, Sep 23, 2019

You’ve found a bug! It looks like it’s even a bug in the spec: when you load a module with a config and that module forwards multiple modules, the config is passed as-is to all those modules, which will basically never do what you want. We need to be more sophisticated about how we handle that interaction.

3reactions
nex3commented, Nov 12, 2019

The proposal has landed! I’m going to give it a couple weeks to accumulate feedback, and then move forward on implementation.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Vivado Design Suite Tutorial: Partial Reconfiguration (UG947) - Xilinx
This tutorial covers the Partial Reconfiguration (PR) software support in Vivado® ... IDE, from establishing the design using the Partial Reconfiguration ...
Read more >
Vivado Design Suite Tutorial: Dynamic Function eXchange
For Operating Systems support, see the Vivado Design Suite User Guide: ... each Reconfigurable Module inserted as a new block design.
Read more >
Partial Reconfiguration in Vivado - Xilinx
Abaco Systems will also talk about how using Vivado Abstract Shell function has assisted them with IP protection and how Dynamic Function eXchange...
Read more >
Vivado Design Suite User Guide - Partial Reconfiguration
Reconfigurable Modules must be initialized to ensure a predictable starting condition after reconfiguration. You can do this manually with a ...
Read more >
A Design Technique for Adapting Number and Boundaries of ...
Design tools should support an arbitrary placement of processing modules and the adjustment of boundaries of reconfigurable regions to the size of the ......
Read more >

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