When using "stencil bundle" is it required to have validated code? It seems it wont export unless the errors are fixed.
It is, yes. But as a temporary solution while in development you can always add some entries to the .eslintignore file (as specified here) present in your root folder. You will have some already there for reference. That will be useful for plugins and modules not written by you that ESLint might not let pass. ;)
Related
I tried reading the documentation but it's not so clear what the goal of this file is. I understand that the Profile defines a set of settings (OS, arch, etc.) used by Conan when a specific client installs packages, but what is the functionality of this settings.yml file?
It's well explained on settings.yml section, on Conan docs.
To summarize, settings.yml works like a template for Conan. Conan reads that file to validate which settings can be used. If you pass a build_type which is not listed in settings.yml, Conan will consider it invalid and raise an error.
It keeps a better pattern for all developers, you know everyone is using similar settings, no typo errors for instance. But you can customize your settings, adding new features, like new OS distro.
But probably you will need to share your settings with your cowokers, as now you have additional values, which is perfectly possible.
Regards.
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!
I have an UglifyJS file watcher set up in IntelliJ IDEA, and it works great while I'm editing -- I modify the source js, the minified version gets created next to it automatically.
However, when I run an Ant build, and it copies the minified versions into the build working dir, the watcher "helpfully" creates doubly minified versions of them (*.min.min.js) in the build working dir, not ok.
I've set the Scope of the watcher to the 'src' module, but apparently that doesn't do what you'd think it would, because the doubles get created when Ant copies files into the 'build' module. Happens when I use IDEA to manually copy a single file from src to build too.
I don't see how to set this up to include *.js but exclude *.min.js, which is really the right thing. (Seems so sensible that Uglify should have it built in, but far as I can see it doesn't.)
Other than getting rid of the watcher and scripting the build do the minification, or copying only the original js versions and letting the watcher (re)create the minified ones, what's the best way to go here?
Got this working, thanks to a helpful commenter on the IDEA forum. The key is setting up a custom Scope, which I tried to do before but failed.
Pattern I ended up with was this, for anyone with similar needs:
file[src]:*.js&&!file:*min.js*
Making the 'src' module current then opening the dlg and selecting it from the dropdown in the main watcher config window apparently doesn't actually filter by that module. Clicking the ... btn, then choosing it from the dlg that opens does, plus I added an explicit filename pattern to exclude already minified files too.
Works great now, far as I've tested (both a minimal Ant test and manually copying a file to 'build' in IDEA).
This is an old question, and perhaps the Watchers didn't have this functionality at the time.
Using JetBrains 'macro' codes makes the 'min.min.min.js' problem go away.
$FileNameWithoutAllExtensions$.js -m --source-map -o $ContentRoot$\prod\js\$FileNameWithoutAllExtensions$.min.js
I always set 'Scope' to 'Current File', too; why run uglify on files that haven't been altered? (I'm assuming that any 3rd party JS libraries are already minified).
I've cloned noflo-ui from github and am running locally but cannot figure out how to add/remove components from the noflo-search box. Ideally, I would like to remove all components from the search results and show only a the ones from my component libraries.
The readme states that libraries can be added by modifying preview/component.json, but removing libraries seems to have no effect. After reading through the docs on components and the spec for component.js I tried editing /component.json, and was also unable to change the results which show in the search box. Furthermore, I can't find any documentation on the .noflo property used in components.json.
Am I doing something wrong or is removing default components not an option?
I assume you are using the bundled noflo-browser runtime (iframe). Did you rebuild after editing preview/components.json?
An easier way to use custom component libraries is to do a custom runtime build, for instance based on noflo-app, host it locally, and switch the runtime URL to point there.
This also works with app.flowhub.io so no need to build & run noflo-ui locally.
In addition to editing preview/component.json, you also have to rebuild the iframe runtime components. To do that, run:
$ grunt build
Note that with newer noflo-ui/Flowhub there is actually no need to build the full UI locally. You can use the hosted Flowhub or even the Chrome app, and simply connect it to an iframe runtime you're running somewhere else:
The noflo-browser-app repo gives a nice base to build these from.