I am building an Aurelia app with TypeScript and decided to try out Semantic UI. I followed this question (Aurelia Semantic dropdown) and it helped me install Semantic into Aurelia. It seems that it got installed already built with default theme. Is there a way I can install semantic into Aurelia TypeScript app, then add some custom gulp tasks to build according to my own theme.config? I would like also to override some variables like colors, font sizes etc. After it is built I'd like to use the built version in Aurelia view models (TypeScript) and in my views. How can I achieve that?
Here is how I solved this:
Installed semantic to some local folder with npm
Copied over the semantic folder and semantic.json to web app root folder (so semantic folder is on the level where I have node_modules and jspm_packages)
Inside semantic.json I specified the list of components I want to include in my app
Inside semantic.json I modified "output" and "clean" paths to match the folders where I serve files from.
The semantic.json:
{
"base": "semantic",
"paths": {
"source": {
"config": "src/theme.config",
"definitions": "src/definitions/",
"site": "src/site/",
"themes": "src/themes/"
},
"output": {
"packaged": "../dist/semantic",
"uncompressed": "../dist/semantic/components/",
"compressed": "../dist/semantic/components/",
"themes": "../dist/semantic/themes/"
},
"clean": "../dist/semantic"
},
"permission": false,
"autoInstall": false,
"rtl": false,
"version": "2.2.4",
"components": [
"button",
...
"site"
]
}
Inside Aurelia's gulp definitions I added semantic build task
The build/tasks/build.js:
var buildSemantic = require('../../semantic/tasks/build');
gulp.task('build-semantic', buildSemantic);
...
gulp.task('build-layout', function (callback) {
return runSequence(
'build-html',
'build-semantic',
'build-less',
callback
);
});
When coding I go into semantic src (e.g. semantic\src\themes\default\globals\site.variables) and modify things in there
Run gulp build-layout
The output is added to my dist folder and I can use it in my views
As for the view models I created some helper components to be used as aurelia attributes e.g. the semantic tooltip:
import {customAttribute, inject} from 'aurelia-framework';
import * as $ from 'jquery';
import '../semantic/semantic.min.js';
#customAttribute('semantic-tooltip')
#inject(Element)
export class SemanticTooltip {
constructor(private element: HTMLElement) {
}
attached() {
$(this.element).popup();
}
}
Usage:
<i class="info circle icon" data-content="Sample tooltip" semantic-tooltip></i>
Related
I am new to pnpm workspaces and am trying to resolve the following issue.
My demo project:
root
packages
common-ui
main-lib
common-ui is a Vite based package containing some Vue components that can be reused by other packages, in my example it's being used by main-lib.
"dependencies": {
"ui-common": "workspace:*"
},
common-ui is referencing an index.ts inside its package.json
"main": "index.ts",
index.ts is exporting my Vue components:
...
export { default as Heading } from './components/Heading/Heading.vue';
...
Now I am able to import those components inside main-lib:
import { Heading } from 'common-ui'
This all works fine but I would also like to be able to publish my library to the npm registry. As common-ui is using the Vite, it's possible to build in library mode: https://vitejs.dev/guide/build.html#library-mode. My package inside common-ui will need to change to:
{
"name": "common-ui",
"files": ["dist"],
"main": "./dist/common-ui.umd.js",
"module": "./dist/common-ui.es.js",
"exports": {
".": {
"import": "./dist/common-ui.es.js",
"require": "./dist/common-ui.umd.js"
}
}
}
main is not referencing index.ts anymore but a dist folder that only gets updated when the vite command is ran. Is there a way for me to support both publishing/versioning and referencing the actual source code from inside main-lib?
I've taken a quick look at Rush.js but I am not sure if provides a solution and I want to be sure before I continue on that path.
I'm trying to use the optimized, es6 build of Mobx, as per the documentation:
Tip: the main entry point of the MobX 5 package ships with ES5 code for backward compatibility with all build tools. But since MobX 5 runs only on modern browsers anyway, consider using the faster and smaller ES6 build: lib/mobx.es6.js. For example by setting up a webpack alias: resolve: { alias: { mobx: __dirname + "/node_modules/mobx/lib/mobx.es6.js" }}
https://mobx.js.org/README.html#browser-support
This allows me to import mobx and get the mobx.es6.js build:
import mobx from 'mobx' // Yay, es6 build!!!
This works great for Webpack-based projects, such as Electron ones, where I already have it working.
For React Native, I can specify extraNodeModules in metro.config.js like so:
module.exports = {
resolver: {
extraNodeModules: {
"mobx": path.resolve(__dirname, 'node_modules/mobx/lib/mobx.es6.js'),
},
},
};
...except that doesn't work, I presume, because the mobx dependency resolves fine on its own, and so this configuration option is never checked.
I can use a separate alias for mobx, such as mobx-es6 but that's not ideal, to put it nicely:
module.exports = {
resolver: {
extraNodeModules: {
// Nooo I don't want to update a bazillion source files!.
"mobx-es6": path.resolve(__dirname, 'node_modules/mobx/lib/mobx.es6.js'),
},
},
};
Is there some other way to configure Metro so that I can override the mobx import like I can with Webpack?
I'm using RN 0.60.0.
The solution is to add a browser section to package.json:
"name": "My React Native Project",
"version": "0.0.1",
"browser": {
"mobx": "mobx/lib/mobx.es6.js"
},
This is undocumented, AFAICT, but there are hints here:
resolverMainFields
Type: Array<string>
Specify the fields in package.json files that will be used by the module resolver to do redirections when requiring certain packages. For example, using ['browser', 'main'] will use the browser field if it exists and will default to main if it doesn't.
https://facebook.github.io/metro/docs/configuration#resolvermainfields
import mobx from 'mobx' // Yay, es6 build!!!
I am creating a custom component library that i want to share across multiple domains.
Domains:
Each domain has its own instance of nuxt
Each domain has my-component-lib registered in package.json
Each domain registers the lib as a plugin
//my-component-lib.js
import components from 'my-component-lib'
import Vue from 'vue'
export default ({ store }) => {
Vue.use(components, { store: store })
}
//nuxt.config.js
plugins: [
/*Desired option 1*/ '#/plugins/my-component-lib',
/*Currently using*/ { src: '#/plugins/my-component-lib', ssr: false }
]
my-component-lib:
Setup using vue-cli 3
The library is composed of basic html tags and CSS ex <input ></input>. The styling is important and i would like to keep it together with the component (extract:false) so i can pull individual components out and not worry about importing a css file.
//vue.config.js
module.exports = {
outputDir: 'dist',
lintOnSave: false,
css: {
extract: false
}
}
setup for production using "production": "vue-cli-service build --target lib --name sc components/index.js"
Problems:
Using the desired option, when i run nuxt npm run dev i get a document is not defined in function addStyle (obj /* StyleObjectPart */) {..} within sc.common.js
Using the current option, i get a hydration error(The client-side rendered virtual DOM tree is not matching server-rendered content.) which is fixed if i wrap the components within <no-ssr> tags which i do not want to do.
I want to compile my component library to work with SSR and not have to import a large css file
Change
...
css: {
extract: false
}
...
to true
I'm trying to move one of my custom elements into a plug-in so that I can re-use it across projects.
I had a look at the skeleton plugin and noticed that it has a src/index.js that returns a config with all custom elements defined as globalResources.
So I tried the same thing and I basically have:
src/index.js
export function configure (config) {
config.globalResources([
'./google-map',
'./google-map-location-picker',
'./google-map-autocomplete'
]);
}
And then I have each one of my custom elements next to index.js, for example:
google-map.js
import {inject, bindable, bindingMode, inlineView} from 'aurelia-framework';
#inlineView(`
<template>
<div class="google-map"></div>
</template>
`)
#inject(Element)
export class GoogleMapCustomElement {
// All the Custom Element code here
}
I've also set up a basic npm script that runs babel on the code and sticks it in dist/:
"main": "dist/index.js",
"babel": {
"sourceMap": true,
"moduleIds": false,
"comments": false,
"compact": false,
"code": true,
"presets": [ "es2015-loose", "stage-1"],
"plugins": [
"syntax-flow",
"transform-decorators-legacy",
"transform-flow-strip-types"
]
},
"scripts": {
"build": "babel src -d dist"
},
Tbh I'm not entirely sure this is all correct but I took some of it from the skeleton plugin and it seems to run fine.
Anyway, the problem I'm having is that after I install the plugin (npm install --save-dev powerbuoy/AureliaGoogleMaps), add it to my aurelia.json in build.bundles[vendor-bundle.js].dependencies and tell aurelia to use it in main.js (.use.plugin('aurelia-google-maps')) I get:
GET http://localhost:9000/node_modules/aurelia-google-maps/dist/index/google-map.js (404)
So my question is, where does it get the dist/index/ part from?? I'm configuring my globalResources in index.js but nowhere does it say that I have an index folder.
What am I doing wrong?
Bonus question: What is the bare minimum required to transpile my ES6 plug-in code so that others can use it? Does my babel configuration look correct?
What about referencing your plugin within aurelia.json, like this:
{
"name": "aurelia-google-maps",
"path": "../node_modules/aurelia-google-maps/dist",
"main": "index"
}
I have absolutely no idea why, but in order to solve this problem I actually had to move my custom elements inside an index/ folder.
So now I have this:
- index.js
- index/
- custom-element-one.js
- custom-element-two.js
And my index.js still looks like this:
export function configure (config) {
config.globalResources([
'./custom-element-one',
'./custom-element-two'
]);
}
Where it gets index/ from I guess I will never know, but this works at least.
I did need the babel plug-in Marton mentioned too, but that alone did not solve the mystery of the made up path.
Edit: To elaborate a bit further, if I name my main entry point something other than index.js the folder too needs that name. For example, if I were to rename index.js main.js I would need to put my globalResources inside a folder called main/.
Update:
Edit: thanks for clarifying why you don't want to use the whole skeleton-plugin package.
Focusing on your original question: aurelia-cli uses RequireJS (AMD format) to load dependencies. Probably, your current output has a different format.
Add transform-es2015-modules-amd to babel.plugins to ensure AMD-style output, so it will be compatible with RequireJS and therefore with aurelia-cli.
"babel": {
"sourceMap": true,
"moduleIds": false,
"comments": false,
"compact": false,
"code": true,
"presets": [ "es2015-loose", "stage-1"],
"plugins": [
"syntax-flow",
"transform-decorators-legacy",
"transform-flow-strip-types",
"transform-es2015-modules-amd"
]
}
Original:
There are several blog post about plugin creation, I started with this: http://patrickwalters.net/making-out-first-plugin/ .
Of course, there have been many changes since then, but it's a useful piece of information and most of it still applies.
I'd recommend using plugin-skeleton as project structure. It provides you with a working set of gulp, babel, multiple output formats out-of-the-box.
With this approach, your plugin's availability wouldn't be limited to JSPM or CLI only but everyone would have the possibility to install it regardless of their build systems.
Migration is fairly easy in your case:
Download skeleton-plugin
Copy your classes + index.js into src/
npm install
...wait for it...
gulp build
check dist/ folder
most of your pain should now be gone :)
Here are some details based on my observations/experience.
1. Main index.js/plugin-name.js:
In general, a main/entry point is required, where the plugin's configure() method is placed. It serves as a starting point when using it within an Aurelia application. This file could have any name, usually it's index.js or plugin-name.js (e.g. aurelia-google-maps.js) to make it clear for other developers what should be included for bundling. Set that same entry point in package.json as well.
In addition to globalResources, you can implement a callback function to allow configuration overrides. That can be called in the application, which will use the plugin. Example solution
Plugin's index.js
export * from './some-element';
export function configure(config, callback) {
// default apiKey
let pluginConfig = Container.instance.get(CustomConfigClass);
pluginConfig.apiKey = '01010101';
// here comes an override
if (callback) {
callback(pluginConfig);
}
...
config.globalResources(
'./some-element'
);
}
Your app's main.js
export function configure(aurelia) {
aurelia.use
.standardConfiguration()
.developmentLogging()
.plugin('aurelia-google-maps', (pluginConfig) => {
// custom apiKey
pluginConfig.apiKey = '12345678';
});
aurelia.start().then(a => a.setRoot());
}
2. HTML and CSS resources:
If you have html only custom elements, you can make them available using globalResources.
Custom css styling is going to require a bit of additional configuration in bundling configuration (see below).
3. Using the plugin with aurelia-cli: Documentation
One of the first new features you'll see soon is a command to help you with 3rd party module configuration. The command will inspect a previously npm-installed package, and make a configuration recommendation to you, automating the process if you desire.
While we are looking forward to that above moment, let's edit aurelia.json:
Configure plugin dependencies. If there are any external libraries (e.g. Bootstrap), then those should be included before your plugin.
Include your plugin:
...
{
"name": "plugin-name",
"path": "../node_modules/plugin-name/dist/amd",
"main": "plugin-name",
"resources": ["**/*.html", "**/*.css"] // if there is any
},
...
Now, your plugin is ready to include it in main.js as showed in Section 1..
I hope you didn't get sick of reading the word 'plugin' so many (21!) times. :D
I have been building a Meteor app and decided to ditch it in favor of phoenix. The problem I am having is trying to integrate a pre-made Bootstrap theme with my app. I need to be able to control the load order of the CSS, Sass, and JavaScript. In Meteor you put the load order in a package.json file and build a custom package for it. Also, you don't have to include import statements in your HTML. So my specific questions are these:
How do I control the load order of the files?
Where should all the JavaScript, CSS, Sass, and images files go? (I'm guessing in the static vendor directory?)
I do need to include the import statements in the HTML files correct?
This theme is pretty big with a bunch of JavaScript files, font awesome, Bootstrap CSS, custom CSS, Sass, images, and the kitchen sink.
In Phoenix this can be accomplished like so:
You'll want to include the sass-brunch package in your package.json file and run npm-install e.g.
{
"repository": {
},
"dependencies": {
"brunch": "^1.8.5",
"babel-brunch": "^5.1.1",
"clean-css-brunch": ">= 1.0 < 1.8",
"css-brunch": ">= 1.0 < 1.8",
"javascript-brunch": ">= 1.0 < 1.8",
"sass-brunch": "^1.8.10",
"uglify-js-brunch": ">= 1.0 < 1.8"
}
}
Now you'll change your app.css located web/static/css/app.css file to app.scss. From here import all of your css/sass files (I personally add bootstrap to the vendor folder under css web/static/vendor/css/bootstrap.scss) e.g.
#import "../vendor/css/bootstrap";
This next part might be the part that you had trouble figuring out, as I =o). What you do for javascript files is require them in your brunch-config.js file like so:
exports.config = {
// See http://brunch.io/#documentation for docs.
files: {
javascripts: {
joinTo: "js/app.js",
order: {
before: [
"web/static/vendor/js/jquery.min.js",
"web/static/vendor/js/bootstrap.min.js",
"web/static/vendor/js/scripts.js"
]
}
},
stylesheets: {
joinTo: "css/app.css"
},
templates: {
joinTo: "js/app.js"
}
},
conventions: {
// This option sets where we should place non-css and non-js assets in.
// By default, we set this to "/web/static/assets". Files in this directory
// will be copied to `paths.public`, which is "priv/static" by default.
assets: /^(web\/static\/assets)/
},
// Phoenix paths configuration
paths: {
// Dependencies and current project directories to watch
watched: [
"deps/phoenix/web/static",
"deps/phoenix_html/web/static",
"web/static",
"test/static"
],
// Where to compile files to
public: "priv/static"
},
// Configure your plugins
plugins: {
babel: {
// Do not use ES6 compiler in vendor code
ignore: [/web\/static\/vendor/]
}
},
modules: {
autoRequire: {
"js/app.js": ["web/static/js/app"]
}
},
npm: {
enabled: true
}
};