I have created my own set of custom SCSS frameworks that I want to use between projects.
This video shows how to do this. However, I am having some problems:
1) The Path to your custom SCSS framework has to be absolute
According to the video, the path to your frame work must be absolute (e.g. load "/Users/USERNAME/ frameworks/MYFRAMEWORK"). Is there a way to make this relative, so if I change machines the framework reference will still be correct?
2) In my custom framework, I have included some webfonts. When the stylesheet is complied, the paths to these fonts is wrong. Is there a way to make the fonts included in my project?
In the end, I used Codekit for this: http://incident57.com/codekit/
It's really easy. Just have a folder on a computer that contains your framework and then set it as a Codekit framework.
You can then use the import command from any SCSS file to import files from the framework.
You can even have a javascript/jquery file framework.
This is easily the best tool for Web Development. I can't imagine development without it.
Related
I am trying to set up sass with Angular Dart but I'm a bit lost and couldn't find a documentation past 2016 (a good one)
I currently have the following structure:
However I cannot reference a main.css file as it is not found and if in a component I put something like this
styleUrls: ['lib/assets/sass/main.scss']
The webdev serve command fails
My pubscpec is
dependencies:
angular: ^5.0.0
angular_components: ^0.9.0
bootstrap_sass: any
dev_dependencies:
angular_test: ^2.0.0
sass_builder: ^2.1.1
build_runner: ^0.10.0
build_test: ^0.10.2
build_web_compilers: ^0.4.0
mockito: ^3.0.0
test: ^1.3.2
I cannot figure out what's wrong and also the structure I should use
Should I put in my top component main.scss (or the compiler main.css) and do not set any other file reference or should I include it at every component? And also how can I generate this compiled file when I run webdev serve
Thanks,
Alexi
So the references for styleUrls should always be the compiled css not the Sass file. Also the Urls need to be either relative to the file, or package format. So either 'main.css' or 'package:your_project/assets/sass/main.css'
I would also suggest not having separate asset directories. I tend to find having the sass file next to the component to be easier to maintain.
AngularDart also has style encapsulation by default; meaning CSS won't leak outside of the Components by default. Given this I find it better to have the CSS local to that component and be next to that component. You'll find that is the pattern on the angular components, and gallery.
One small note on the components, and gallery. They use the pattern style.scss.css instead of style.css which breaks the convention of Sass. The reasoning behind it is so that we can quickly tell what the source of the CSS file was. Was it written by hand, or did it come from Sass. This is achieved by having different settings in the build.yaml file. I don't think you should do this for your project tho.
I'm developing an app in typescript (in Visual Studio 2015) and have this basic file structure:
Solution
AppProject
Scripts
framework
Utils.ts
app
SomeApp.ts
tsconfig.json
Now within the app modules, I would like to reference the framework modules with an absolute path, so I would do something like this:
import { Utils } from '/Scripts/framework/Utils'
However this doesn't work.
I'm getting the red squiggly line and a "Cannot find module '/Scripts/framework/Utils'"
I works fine when doing a relative path, but the app is obviously more complex than what is shown, and I don't want to deal with stepping out multiple levels for my relative path.
I am using typescript 1.8 with the node module resolution strategy.
And webpack to compile and bundle it, if that matters
Unfortunately I couldn't find anything on that in the docs. So I traced the file system accesses performed by the compiler (TypeScript 2.5.2) when trying to resolve an import of an absolute path.
The result is that / always refers to the file system root. Regardless of compilerOptions like rootDir, rootDirs or baseUrl.
I've run into a rather annoying issue.
We have a very large code base which is mostly legacy code, and we have just begun implementing bootstrap. We have to "namespace" or "wrap" the bootstrap code in a class so that we can apply bootstrap to only parts of a page without affecting anything else.
If you're familiar with this technique, the common workaround is this:
.bootstrap-wrapper {
#import (less) "bootstrap.css";
}
See this issue: https://github.com/less/less.js/issues/1709
This works great as long as bootstrap.css is not minified. For whatever reason (probably something to do with semicolons), the minified version is not valid less even though it is valid css, and the less compiler errors out.
This wouldn't be much of an issue, except we are using Web Essentials (for VS 2013 update 4) to automatically compile our less into minified css files, and there is no granularity whatsoever.
We have the option to compile the unminified css files turned off, because we have no use for them, and only need the minified files. Since Web Essentials is all or nothing, there's no way for me to compile the unminified file in just this one case. We would have to carry an extra css file for every single compiled less file just to support this one case.
Are there any alternatives to creating a wrapper class this way, or is there anything I can do with Web Essentials to make this work?
I am new to browser development, so I have no prior experience with AMD, CommonJS, UMD, Browserify, RequireJS, etc. I have been reading a lot about them and I believe I generally understand the JavaScript story but I am still very confused as to how to make everything work together.
I have a library written in TypeScript. It is a pure TypeScript library, it doesn't interact with a browser or any browser framework nor any node or NPM things.
I also have a TypeScript client application that leverages this library. The client application may leverages a web framework as well (e.g., jQuery).
Now when I compile my two TypeScript files (which we will assume are in separate projects, isolated from each other and built separately), each will generate a .js file. In Visual Studio I have to choose AMD or Common as my module loader.
This is where things fall apart. My research tells me that if I want to work on the web I either need to use Browserify or RequireJS. Browserify appears to require I first install Node on my machine and then use a command line tool as a post-build step to generate a file and as far as I can tell this isn't available as a NuGet package. Alternatively, I can use RequireJS but then all of the examples stop working. Something about not doing things on window load and instead doing them somewhere else, but nothing that I have found really explains that well.
So, what is the story here? I want to use TypeScript but at the moment it really feels like it is just a language, there aren't any compelling usage stories available to me as a developer as I have grown accustomed to in the Microsoft ecosystem.
TypeScript does support AMD and CommonJS just as JavaScript. But in addition it also supports internal modules. When using internal modules in conjunction with a decent build system like gulp-typescript you'll find that internal modules can cover lot of use cases where one would choose AMD/CommonJS in traditional JavaScript projects.
TypeScript gives you the freedom to decide yourself. If you need asynchronous module loading you are free to use AMD via external modules. You can also use CommonJS and/or use browserify to link together your code into a single file.
I've found that when you are a library developer - that is you ship your TypeScript compiled JS code to other developers - internal modules are a good compromise. You don't force your target audience (developers) to use any special module system like AMD/CommonJS, but instead ship isomorphic JS that runs in the browser as well as in node. Yet you still have a way of modularizing your code internally, just as AMD/CommonJS would allow you.
TL;DR: When you use TypeScript you get internal modules for free, and they provide you with a flexibility that would else only be achieved by AMD/CommonJS. Yet external modules still have their advantages. In the end, you should decide what is the best fit for your project.
TypeScript is a superset of JavaScript so its story is the story of JS, not of .NET or any other Microsoft product.
If you compile your TypeScript modules to AMD, then you load them through an AMD module loader like RequireJS (or Dojo, or curl) in your entrypoint HTML file, which can be as simple as this (using RequireJS):
<!DOCTYPE html>
<title>Application name</title>
<script src="scripts/require.js" data-main="scripts/client"></script>
(Assuming that your built TypeScript module is scripts/client.js.)
The Start page for RequireJS or the Dojo Introduction to AMD modules are both resources that can tell you more about how to load AMD-formatted modules in a browser.
You got a really good technical answer from C Snover, but the answer you're actually looking for is "don't use external modules". By external modules, I mean "AMD" or "CommonJS" modules.
If you actually need what external modules offer, they can be very useful, but they come at a significant cost in terms of build/deployment complexity and concepts that you need to understand.
Just because external modules are way more complicated doesn't mean they're better; the TypeScript compiler itself is written using internal modules.
You can convert an external module back to an internal module by omitting any export statements on the module itself (and by not having an export = statement at the end of the file either). For example, this is an internal module:
module MyLibrary {
export class MyClass {
public Foo = 1;
}
}
If you are using internal modules, all you have to do is reference them in the right order via script tags in your HTML files and they will work without having to deal with any sort of loader system.
<script src="MyLibrary.js"></script>
<script src="MyUICode.js"></script>
When i upgrade the version the css and theme is taking the default one .Architect shows error as
Theme Error saving theme.Cmdenabled projects need to have a local library base path.Yours is set to "http://cdn.sencha.com/touch/sencha-touch-2.2.1/"
likely you will want to set your library base path to to touch/, do this by selecting the Library node under resources.