Use babel@7 and webpack@4 to build#156
Conversation
| @@ -0,0 +1,18 @@ | |||
| [*] | |||
| charset=utf-8 | |||
| end_of_line=crlf | |||
There was a problem hiding this comment.
👎
This should not be necessary with the git attribute
There was a problem hiding this comment.
.editorconfig is an editor/ide agnostic config used for formatting and is mutually exclusive from git attribute. For open source, these are important since a wide range of editors support it even if there is some duplication
There was a problem hiding this comment.
We should allow our editors to write the file with their native line ending. Git will convert it to whatever your os prefers on checkout.
There was a problem hiding this comment.
also to be clear, I just mean removing the end_of_line config, not the entire editor config.
There was a problem hiding this comment.
This is inconsequential since all modern platforms recognize \r\n, especially editors editing js. ¯_(ツ)_/¯
We can remove it if it unblocks this PR. I think we should have some more consistent guidelines around what constitutes blocking a PR by requesting changes. It seems silly to prevent this PR from going in because of this.
There was a problem hiding this comment.
Removed for now. Let's discuss it later in meetings.
There was a problem hiding this comment.
That's incorrect. Shell scripts must have unix line endings.
There was a problem hiding this comment.
it looks like the editorconfig project has quite a discussion on this. it seems inconclusive but generally the recommendation is the following:
end_of_line
Line ending file format (Unix, DOS, Mac)The values are case insensitive. They will be lowercased by the core library.
NOTE: if you want to use native line endings between different operating systems it is better not to set this option and leave that task to the VCS! In the future we might add a value like native for this scenario (cf #226).
thread: editorconfig/editorconfig#226
There was a problem hiding this comment.
Sorry. I did't realize we are using shell scripts in this project.
a-b-r-o-w-n
left a comment
a-b-r-o-w-n
left a comment
There was a problem hiding this comment.
Overall this looks good. There is one thing that I don't think is needed in the editorconfig though
|
Pinged @justinwilaby, the original author of |
|
It's in! |
4 participants
Implementation
Instead of using
ts-loaderto build during Webpack, we are using Babel to do all transpilation.As suggested by TypeScript team, the following plugins and presets are used.
@babel/plugin-proposal-class-properties@babel/plugin-proposal-object-rest-spread@babel/preset-typescript@babel/preset-envIn addition, we will use
@babel/plugin-transform-runtimeto bundle@babel/runtime.We kept the original file architecture (
/directLine.js,/built/directLine.js), instead of opting for a more modern approach. This is a consideration for users using our bundle thru https://unpkg.com/botframework-directlinejs/directLine.js.This PR also added a test harness which will emulate response from Azure Bot Services.
Also added a test page for trying out
directLine.jsbundle in pure JavaScript (without Web Chat). This is useful because some of our customers use DirectLineJS directly from CDN. We should turn this test page into a sample later.Changelog
Changed
@babel/preset-typescriptandwebpack@4to build, in PR #156.editorconfigand.vscodefor new line and tab size rules