Skip to content

feat: merge master into webpack branch #4627

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 101 commits into from
May 21, 2019

Conversation

Fatme
Copy link
Contributor

@Fatme Fatme commented May 17, 2019

PR Checklist

What is the current behavior?

What is the new behavior?

Fixes/Implements/Closes #[Issue Number].

Fatme and others added 30 commits April 15, 2019 09:07
chore: add changelog for 5.3.2 release
fix: fix upload to appstore for accounts without 2 factor authentication
# Conflicts:
#	lib/bootstrap.ts
#	npm-shrinkwrap.json
#	package.json
    Currently CLI merges and prepares xcconfig files only for the current build configuration, i.e. debug or release. However, the `pod install` command works with both configurations. This leads to problem when some property is set in the project's (plugin's) build.xcconfig file as CLI will prepare the native iOS project only for one configuration. When `pod install` is executed, if the Pods project uses the property set in the build.xcconfig file, it will fail with error, as the value for debug and release will be different (i.e. it will be set only for one of them). Pods project does not support this behavior, so the build operation fails.

    So, ensure CLI merges all xcconfig files for both debug and release configurations. This way, the Pods project will be in sync, so it should continue its execution. This is important when using Cocoapods 1.6.0+ where some changes are applied for Swift support, which can be workarounded by setting SWIFT_VERSION in project's build.xcconfig file.
…g-all-configs

fix: prepare xcconfig files for all conigurations
…nings

feat: deprecate the legacy workflow and recommend the new one
Do not use the proxy for requests to localhost or 127.0.0.1 when NativeScript is configured to use the proxy.

Partially fixes issue #2313, since requests to localhost will be possible in corporate proxy environments.
… as the string literals are always generating "/n" terminating lines based on the below-mentioned ES specification)

More details here: http://exploringjs.com/es6/ch_template-literals.html#_line-terminators-in-template-literals-are-always-lf-n
8.2.3 Line terminators in template literals are always LF (\n) #
Common ways of terminating lines are:

Line feed (LF, \n, U+000A): used by Unix (incl. current macOS)
Carriage return (CR, \r, U+000D): used by the old Mac OS.
CRLF (\r\n): used by Windows.
`All of these line terminators are normalized to LF in template literals.` That is, the following code logs true on all platforms:

const str = `BEFORE
AFTER`;
console.log(str === 'BEFORE\nAFTER'); // true
…gs-windows

fix: fix the workflow warnings on Windows
chore: add changelog for 5.3.3 and 5.3.4
rosen-vladimirov and others added 20 commits May 9, 2019 17:42
style: misleading warning message
Several plugin use deleted logger methods in their hooks. Same is valid for `nativescript-cloud` extension.
To resolve this, get back the deleted methods, we'll delete them in 6.0.0 release.

Also, `nativescript-cloud` has an option `--workflow`, that is an object, while ours is boolean. This breaks its transpilation, so set ours to `any`.
…tible

fix: make logger backwards compatible
…ript-dev-xcode

chore: update nativescript-dev-xcode to 0.2.0
fix: set correct link for legacy workflow warning
There are two new prompts in the plugin seed which require new command line options to be passed from CLI. Handle the new prompts and pass the new options. They can be used in automation scripts.
In order to prevent such issue in the future, ensure the spawned process's stdout and stdin are inherited, so if there's a prompt in the plugin seed, CLI will show it to the user.
fix: plugin create command needs more args for plugin seed
docs: update changelog for 5.4.0 release
chore: merge release-patch in release
# Conflicts:
#	lib/bootstrap.ts
#	lib/commands/appstore-upload.ts
#	lib/commands/build.ts
#	lib/commands/clean-app.ts
#	lib/commands/debug.ts
#	lib/commands/deploy.ts
#	lib/commands/list-platforms.ts
#	lib/commands/prepare.ts
#	lib/commands/run.ts
#	lib/commands/test.ts
#	lib/commands/update.ts
#	lib/definitions/platform.d.ts
#	lib/definitions/xcode.d.ts
#	lib/helpers/bundle-validator-helper.ts
#	lib/services/ios-project-service.ts
#	lib/services/livesync/playground/preview-app-livesync-service.ts
#	lib/services/platform-service.ts
#	lib/services/plugins-service.ts
#	lib/services/test-execution-service.ts
#	lib/tools/node-modules/node-modules-dest-copy.ts
#	test/debug.ts
#	test/ios-project-service.ts
#	test/nativescript-cli-lib.ts
#	test/platform-commands.ts
#	test/platform-service.ts
#	test/stubs.ts
#	test/update.ts
@cla-bot cla-bot bot added the cla: yes label May 17, 2019
@ghost ghost assigned Fatme May 17, 2019
@ghost ghost added the new PR label May 17, 2019
@Fatme Fatme changed the title Fatme/merge master webpack feat: merge master into webpack branch May 17, 2019
@Fatme Fatme force-pushed the fatme/merge-master-webpack branch from f218f6b to 44eb3c5 Compare May 20, 2019 12:07
@Fatme Fatme merged commit 8fb4330 into feature/webpack-only May 21, 2019
@Fatme Fatme deleted the fatme/merge-master-webpack branch May 21, 2019 05:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants